Subject: [ssm] URGENT: draft-ietf-ssm-arch-06.txt

From: Toerless Eckert <[email-masked]>
Date: Tue, 4 Oct 2005 02:13:38 -0700

Can somebody please tell me what needs to be done to get an SSM
architecture RFC out of that draft... like: This year ?

We've got a whole bloody broadband industry like in DSL and Cabl
where it's extremely difficult to propose and require SSM support without
having an actual IETF RFC for this still pretty badly understood model.

In addition, there is at least one further IETF draft hanging on the
normative reference.

Is there any relationship between the amount of changes / improvement
that went into this draft and it's lifetime ? Or is it rather that this
draft is hanging around waiting for someone who is not spending the time
to move it forward ? If so, can we please identify that roadblock and
get rid of it so that this draft can move forward with a little bit
accelerated speed ? 

Short of this: Can we simply define timeouts of let's say 5 years after
which drafts that have an interested user community become an RFC even
if not all bureaucracy nitpicking has been resolved ? After all, the
PIM-SM RFC2362 also had 120 known bugs when we started out redoing it
something like 5 years ago, but it's pure existance has helped to
ensure that THE INDUSTRY HAS CONTINUED TO DO ANY FORM OF PIM DURING THE
LAST 5 YEARS... *sigh* sorry for getting so loud. Just wanted to highlight
that the situation in SSM is worse than in PIM - with similar waiting
times - because in SSM there is no prior RFC whatsoever that could be
used instad of the real thing, and i really don't see the value of
indefinite postponement anymore.

Thanks
    Toerless Eckert

_______________________________________________
ssm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ssm

---

From: Brian Haberman <[email-masked]>
Date: Tue, 4 Oct 2005 09:23:20 -0400

Hi Toerless,
      Well, the draft is in Revised ID Needed state after IESG review.
https://datatracker.ietf.org/public/pidtracker.cgi? 
command=print_ballot&ballot_id=1300&filename=draft-ietf-ssm-arch

To my knowledge, the editors/authors have either: run out of cycles
or motivation.  I would love to see this draft finished as well.  If  
needed,
I could try and help resolve the DISCUSS comments.

Regards,
Brian

---

From: Hugh Holbrook <[email-masked]>
Date: Tue, 4 Oct 2005 09:01:33 -0700

On 10/4/05, Toerless Eckert <[email-masked]> wrote:
> architecture RFC out of that draft...

Hi, Toerless (and the rest of the wg):

Thanks for the nudge (shove? :)).  I'm glad to hear that you still
care about seeing all the work we've done get finished.

The draft is moving again.  Here's where it's at, with a little
history mixed in.

This draft went through an IESG review last fall, and there was a
DISCUSS about the security considerations section, as well as some
non-blocking comments by Pekka and others that were fairly
straightforward to do.  You can see the full record of comments here:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8276&rfc_flag=0

Alex and Bill and I sorted out a plan back in Minneapolis, and then I
got a new job and the draft stalled for lack of author time until
about a month ago when Alex bugged me again.

I have revised the draft and this version, I believe, addresses all of
the outstanding DISCUSS comments, and it will show up in the id
archives shortly.  I pinged Russ (who authored the DISCUSS), and
pending an ok from him, I think the draft is ready to advance.

There is also a DISCUSS by Brian Carpenter, but I think, and Alex
agrees, that Brian's concern is actually addressed in the document a
little bit below the text he was saying was unclear.

If you are interested in seeing the draft advance, please review the
-07 draft changes, and let me know if you spot anything that might
block a final pass through the IESG.  The diffs relative to the -06
revision are attached below.  I plan to optimistically submit these
changes and revise to an -08 version if the DISCUSS authors aren't
happy with what I've done.

I'll ping the working group again when the -07 draft actually shows up
in the archives, but there haven't been any changes of real substance
-- just clarifications and corrections to RFC numbers, etc, so I'm not
inclined to do yet another wg last call.

If anyone feels that we *really* need another last call for this,
please say so, but I'm hoping that we can harness the momentum
provided by your push here and get this document onto the accelerated
RFC track.

Thanks,
-Hugh

--- draft-ietf-ssm-arch-06.txt	2004-09-07 22:39:33.000000000 -0700
+++ draft-ietf-ssm-arch-07.txt	2005-10-04 08:43:50.000000000 -0700
@@ -5,21 +5,21 @@

 INTERNET-DRAFT          Source-Specific Multicast            H. Holbrook
-Expires Mar 07, 2005                                       Cisco Systems
+Expires Apr 04, 2006                                       Arastra, Inc.
                                                                  B. Cain
                                                         Storigen Systems
-                                                              7 Sep 2004
+                                                              4 Oct 2005

                     Source-Specific Multicast for IP
-                      <draft-ietf-ssm-arch-06.txt>
+                      <draft-ietf-ssm-arch-07.txt>

 Status of this Memo

 By submitting this Internet-Draft, I certify that any applicable patent
 or other IPR claims of which I am aware have been disclosed, and any of
-which I become aware will be disclosed, in accordance with RFC 3667.
+which I become aware will be disclosed, in accordance with RFC 3668.

 Internet-Drafts are working documents of the Internet Engineering Task
 Force (IETF), its areas, and its working groups.  Note that other groups
@@ -57,19 +57,19 @@

 Holbrook/Cain                                                   [Page 1]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

 Abstract

-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.
+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.

 1.  Introduction

@@ -81,10 +81,10 @@
 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 2373 [RFC2373] specifies
+model of multicast defined in RFC 1112.  RFC 3513 [RFC3513] specifies
 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
 addresses and are reserved for use by source-specific applications and
 protocols [IANA-ALLOCATION].
@@ -107,13 +107,13 @@
 allocation by a host, as described in [IPV6-MALLOC].  Addresses in the
 range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM
 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

 Holbrook/Cain                                                   [Page 2]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

 that  P=1 and T=1, hence their designation as invalid).  The treatment
@@ -169,7 +169,7 @@

 Holbrook/Cain                                                   [Page 3]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

 Multicast resource discovery of the form in which a client sends a
@@ -225,7 +225,7 @@

 Holbrook/Cain                                                   [Page 4]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

 Multiple source applications on different hosts can use the same SSM
@@ -281,7 +281,7 @@

 Holbrook/Cain                                                   [Page 5]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

 receiver operations allowed on a channel are called "Subscribe(S,G)" and
@@ -337,7 +337,7 @@

 Holbrook/Cain                                                   [Page 6]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

     channel is desired on multiple interfaces, Subscribe is invoked once
@@ -354,6 +354,12 @@
 non-source-specific request to receive multicast sent to an SSM
 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.,
 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
@@ -383,29 +389,27 @@
 I, the host IP module sends an unsubscription request for that channel
 to interface I.

-These requests will typically be Internet Group Management Protocol
-version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery
-Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2].  A host that
-supports the SSM service model MUST implement the host portion of
-[IGMPv3] for IPv4 and [MLDv2] for IPv6.  It MUST also conform to the
-

 Holbrook/Cain                                                   [Page 7]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

+These requests will typically be Internet Group Management Protocol
+version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery
+Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2].  A host that
+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/MLDv2 behavior described in [GMP-SSM].

 4.3.  Allocation of Source-Specific Multicast Addresses

-The SSM destination address 232.0.0.0 is reserved, and a system MUST NOT
-send a datagram with a destination address of 232.0.0.0.  The address
-range 232.0.0.1-232.0.0.255 is currently reserved for allocation by
-IANA.  SSM destination addresses in the range FF3x::4000:0000 through
-FF3x::7FFF:FFFF are similarly reserved for IANA allocation
-[IPv6-MALLOC].
+The SSM destination address 232.0.0.0 is reserved, and it must not be
+used as a destination address.  The address range 232.0.0.1-232.0.0.255
+is currently reserved for allocation by 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
 applications is strictly locally determined by the sending host.
@@ -440,17 +444,18 @@
 This document neither defines the interfaces for requesting or returning
 addresses nor specifies the host algorithms for storing those
 allocations.  One plausible abstract API is defined in RFC 2771
-[RFC2771].  Note that RFC 2771 allows an application to request an
-address within a specific range of addresses.  If this interface is
-used, the starting address of the range SHOULD be selected at random by
-the application.

 Holbrook/Cain                                                   [Page 8]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005
+

+[RFC2771].  Note that RFC 2771 allows an application to request an
+address within a specific range of addresses.  If this interface is
+used, the starting address of the range SHOULD be selected at random by
+the application.

 For IPv6, administratively scoped SSM channel addresses are created by
 choosing an appropriate scope identifier for the SSM destination
@@ -495,19 +500,19 @@
 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
 expected that this will be commonplace.  In such a network, a router may
-receive a non-source-specific, or "(*,G)" in conventional terminology,
-request for delivery of traffic in the SSM range from a neighbor that
-does not implement source-specific multicast in a manner compliant with
-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

 Holbrook/Cain                                                   [Page 9]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

+receive a non-source-specific, or "(*,G)" in conventional terminology,
+request for delivery of traffic in the SSM range from a neighbor that
+does not implement source-specific multicast in a manner compliant with
+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
 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
 to any request received from a host, e.g., an IGMPv1 or IGMPv2 host
@@ -535,63 +540,50 @@
 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
+topics are addressed: IPsec, denial of service attacks, source spoofing,
+and security issues related to administrative scoping.

-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.
+7.1.  IPsec and SSM

-[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 IPsec Authentication Header (AH) and Encapsulating Security Payload
+(ESP) can be used to secure SSM traffic, if a multicast-capable
+implementation of IPsec (as required in [IPSECbis]) is used by the
+receivers.

-    - the packet's destination IP address

-    - the IPSec protocol (ESP or AH)
+7.2.  SSM and RFC2401 IPsec caveats

+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

 Holbrook/Cain                                                  [Page 10]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
-
-
-    - the Security Parameter Index (SPI)
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

-A problem arises for SSM because the source address is not included in
-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
-simultaneously to two unrelated channels using IPSec whose sources
-happen to have chosen the same IP destination address (IPDA) and the
-same IPSec SPI.  The <IPDA,SPI> tuple, however, consists of 56 bits that
-are generally randomly chosen, and a conflict is unlikely to occur
-through random chance.
+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.

-But when this problem occurs, however unlikely, a host will not be able
-to simultaneously receive IPSec-protected traffic from the two colliding
-sources under the current IPSec model.
+A problem arises if a receiver subscribes simultaneously to two
+unrelated channels using IPsec whose sources happen to be using the same
+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
-separate document.  One possible solution is to include the source
-address in the SAD lookup when the destination is an SSM address.
+If such a collision occurs, a receiver will not be able to
+simultaneously receive IPsec-protected traffic from the two colliding
+sources.

-7.2.  Denial of Service
+7.3.  Denial of Service

 A subscription request creates (S,G) state in a router to record the
 subscription, invokes processing on that router, and possibly causes
@@ -613,13 +605,6 @@
 To reduce the damage from such an attack, a router MAY have
 configuration options to limit, for example, the following items:

-
-
-Holbrook/Cain                                                  [Page 11]
-
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
-
-
     - The total rate at which all hosts on any one interface are allowed
     to initiate subscriptions (to limit the damage caused by forged
     source-address attacks)
@@ -627,6 +612,14 @@
     - The total number of subscriptions that can be initiated from any
     single interface or host.

+
+
+
+Holbrook/Cain                                                  [Page 11]
+
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005
+
+
 Any decision by an implementor to artificially limit the rate or number
 of subscriptions should be taken carefully, however, as future
 applications may use large numbers of channels.  Tight limits on the
@@ -640,15 +633,16 @@
 We note that these attacks are not unique to SSM -- they are also
 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
 violate the SSM service model by transmitting datagrams on a channel
 belonging to another host.  Thus, an application requiring strong
 authentication should not assume that all packets that arrive on a
 channel were sent by the requested source without higher-layer
-authentication mechanisms.  The IPSEC Authentication Header [IPSEC] may
-be used to authenticate the source of an SSM transmission, for instance.
+authentication mechanisms.  The IPSEC Authentication Header
+[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
 is already fairly widespread, because the commonly deployed IP multicast
@@ -665,7 +659,13 @@
 source spoofing mechanisms such as source address filtering at the edges
 of the network are also strongly encouraged.

+7.5.  Administrative Scoping

+Administrative scoping should not be 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 to create such scoping if necessary.

@@ -673,17 +673,9 @@

 Holbrook/Cain                                                  [Page 12]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

-7.4.  Administrative Scoping
-
-Administrative scoping should not be 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 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
@@ -715,31 +707,31 @@

 9.  IANA Considerations

-Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses
-in the range FF3x:4000:0000 to FF3x::7FFF:FFFF are reserved for services
-with wide applicability that either require or would strongly benefit if
-all hosts used a well-known SSM destination address for that service.
-IANA shall allocate addresses in this range according to IETF Consensus
-[IANA-CONSIDERATIONS].  Any proposal for allocation must consider the
-fact that, on an Ethernet network, all datagrams sent to any SSM
-destination address will be transmitted with the same link-layer
-destination address, regardless of the source.  Furthermore, the fact
+IANA allocates IPv4 addresses in the range 232.0.0.1 through 232.0.0.255
+and IPv6 addresses in the range FF3x:4000:0000 to FF3x::7FFF:FFFF.
+These addresses are allocated according to IETF Consensus [IANA-
+CONSIDERATIONS].  These address ranges are reserved for services with
+wide applicability that either require or would strongly benefit if all
+hosts used a well-known SSM destination address for that service.  Any
+proposal for allocation must consider the fact that, on an Ethernet
+network, all datagrams sent to any SSM destination address will be
+transmitted with the same link-layer destination address, regardless of
+the source.  Furthermore, the fact that SSM destinations in 232.0.0.0/24
+and 232.128.0.0/24 use the same link-layer addresses as the reserved IP
+multicast group range 224.0.0.0/24 must also be considered.  Similar
+consideration should be given to the IPv6 reserved multicast addresses.

+Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM
+destination address to a particular entity or application.  To do so
+would compromise one of the important benefits of the source-specific

-Holbrook/Cain                                                  [Page 13]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
+Holbrook/Cain                                                  [Page 13]

+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

-that SSM destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same
-link-layer addresses as the reserved IP multicast group range
-224.0.0.0/24 must also be considered.  Similar consideration should be
-given to the IPv6 reserved multicast addresses.

-Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM
-destination address to a particular entity or application.  To do so
-would compromise one of the important benefits of the source-specific
 model: the ability for a host to simply and autonomously allocate a
 source-specific multicast address from a large flat address space.

@@ -781,21 +773,23 @@
 (Revised)," draft-ietf-pim-sm-v2-new-10.txt (Work in Progress), July
 2004.

+[RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program
+Protocol Specification," September 1981.

+[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112,
+August 1989.

-Holbrook/Cain                                                  [Page 14]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004

-[RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program
-Protocol Specification," September 1981.

-[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112,
-August 1989.
+Holbrook/Cain                                                  [Page 14]

-[RFC2373] Hinden, R. and Deering, S.  "IP Version 6 Addressing
-Architecture."  RFC 2373, July 1998.
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005
+
+
+[RFC3513] Hinden, R. and Deering, S.  "IP Version 6 (IPv6) Addressing
+Architecture."  RFC 3513, April 2003.

 12.  Informative References

@@ -824,28 +818,31 @@

 [PIM-DM] Adams, A., Nicholas, J., and Siadak, W.  "Protocol Independent
 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
 Requirement Levels," RFC 2119, March 1997.

+[IPSECbis] S. Kent, K. Seo, "Security Architecture for the Internet
+Protocol.", draft-ietf-ipsec-rfc2401bis-06.
+
 [RFC2710] S. Deering, W. Fenner, B. Haberman, "Multicast Listener
 Discovery (MLD) for IPv6", RFC 2710, October 1999.

 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address
 Allocation," RFC 2771, February 2000.

+[SCOPINGV6] S. Deering, B. Haberman, T.
+     Jinmei, E. Nordmark, B. Zill, "IPv6 Scoped Address Architecture",
+RFC4007, March 2005.

 Holbrook/Cain                                                  [Page 15]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
-
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

-[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.
 Maufer, C. Diot, and M. Green.  "Simple Multicast: A Design for Simple,
@@ -864,15 +861,16 @@

      Hugh Holbrook
-     Cisco Systems
-     170 W. Tasman Drive
-     San Jose, CA 95134
-     [email-masked]
+     Arastra, Inc.
+     P.O. Box 10905
+     Palo Alto, CA 94303
+     [email-masked]
+     Phone: +1 650 331-1620

 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
 set forth therein, the authors retain all their rights.

@@ -892,16 +890,15 @@
 document or the extent to which any license under such rights might or
 might not be available; nor does it represent that it has made any
 independent effort to identify any such rights.  Information on the
+procedures with respect to rights in RFC documents can be found in BCP
+78 and BCP 79.

 Holbrook/Cain                                                  [Page 16]
 
-INTERNET-DRAFT          Source-Specific Multicast            07 Sep 2004
-
+INTERNET-DRAFT          Source-Specific Multicast            04 Oct 2005

-procedures with respect to rights in RFC documents can be found in BCP
-78 and BCP 79.

 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an attempt
@@ -916,7 +913,10 @@
 standard.  Please address the information to the IETF at ietf-
 [email-masked].

-This document expires Mar 07, 2005.
+This document expires Apr 04, 2006.
+
+
+

---

From: Hugh Holbrook <[email-masked]>
Date: Tue, 4 Oct 2005 09:12:40 -0700

> The diffs relative to the -06 revision are attached below.

Here are the diffs in rfcdiff side-by-side format, which is more
readable, IMO.  In case you're inclined to review them.

http://thoop.net/ssm/draft-ietf-ssm-arch-from--06.diff.html

Thanks,
-Hugh