Source-Specific Multicast for IP
RFC 4607

Note: This ballot was opened for revision 07 and is now closed.

(Harald Alvestrand) Discuss

Discuss (2004-10-13 for -)
I believe the lack of clarity Spencer noted about ASM/SSM deserves to be addressed. Either it should be known to work or it should be known to not work.

Spencer said:

4.1, top of page 7 - This section makes me think ASM listeners won't
  be able to listen to SSM traffic, but the document doesn't
  explicitly say so, one way or the other. It's a little less vague on
  SSM listeners and ASM traffic, but could be clearer here, too.

His other comments are worth thinking about, but I don't think they should be blocking.
Comment (2004-10-13 for -)
No email
send info
Reviewed by Spencer Dawkins, Gen-ART

His review:

This document is on the right track, but is still a couple of stops
from the end of the line :-)

Introduction - The first four paragraphs aren't appropriate for an
Introduction - they are fine, but they should be in a following
section, by themselves. The fifth paragraph begins a high-level
description and justification of SSM - THAT'S what an Introduction
should look like.

4.1, top of page 7 - This section makes me think ASM listeners won't
  be able to listen to SSM traffic, but the document doesn't
  explicitly say so, one way or the other. It's a little less vague on
  SSM listeners and ASM traffic, but could be clearer here, too.

4.3 - No justification of the MUST NOT for In general, the
      justifications in this section are weak, missing, or separated
      from specific requirements. I'm sure the authors understand all
      this stuff; the goal is that people who DIDN'T write the
      document will know how to extend it in the future.

7.1 - points out that SSM can break in the presence of SPI collisions
      by two senders, but doesn't say whether either senders or
      receivers can detect this condition automatically - they promise
      a solution, but don't describe the ability of participants to
      identify the problem in the meanwhile.

7.1 and 7.3 call out AH - my impression is that the use of AH in
    standards-track protocols is almost non-existent, and Steve
    Bellovin keeps telling me that there's no reason for AH. Probably
    good if these sections aren't too dependent on AH.

7.2 Not sure where "A router MAY have a configuration option to allow
    source routing" came from - I think this is actually an
    unintentional use of capitals; surely router requirements for
    source routing support aren't being specified in the security
    considerations section of SSM :-)

8 is called "Transition Considerations". What's the vision here -
coexistence or transition from ASM to SSM? Is it the same vision in
IPv4 and IPv6?

(Bill Fenner) (was Discuss, Yes) Yes

(Allison Mankin) Yes

Comment (2004-10-14 for -)
No email
send info
Some other groups (RMT is one) have been eagerly awaiting this.  It's clear and well-written.
I hope that the IESG discussion will resolve with clarity.  If it would be helpful to have some RMT 
developers who depend on this technology, and intend to use it security features, participate
in any discussions, let me know.

(Alex Zinin) Yes

(Steven Bellovin) (was Discuss) No Objection

(Brian Carpenter) (was Discuss) No Objection

(Margaret Cullen) (was Discuss, No Objection) No Objection

(Ted Hardie) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2005-10-10)
No email
send info
Overall, I am happy with the update.  There is a cut-and-paste problem at
the end of the first paragraph in section 7.2.  The meaning is unclear.

(David Kessens) No Objection

Comment (2004-10-27 for -)
No email
send info
From Pekka Savola, OPS directorate:

From 'high view', I think this is OK.  The comments in the tracker
need to be taken into account.  SSM is already out there, and many
other related specs already specify a lot of the same things that this
spec does, but from a different perspective.

As a bigger comment:

As a matter of fact, IMHO a lot clarity problems that seem to have
come up from those who first read the spec stem from the fact that the
specification has been distributed in a large number of documents, and
there is substantial overlap.  At least these deal with SSM:

 - 'ssm overview', RFC 3569
 - 'ssm architecture', this document
 - draft-ietf-mboned-ssm232-08.txt [rfc ed queue]
 - draft-holbrook-idmr-igmpv3-ssm-08.txt [rfc ed queue]
 - [ draft-ietf-pim-sm-v2-new ]

For example, draft-ietf-mboned-ssm232-08.txt specifies much better how
the hosts and routers should treat with ASM inside the SSM prefix.
I think the reasoning has been that the architecture describes the
generic architecture, and protocols or address ranges are described in
other documents as they might change a bit more, but I don't think
this has entirely successful, because the architecture has ended up
also discussing the protocols and numbers a lot, which was not the
original intent AFAICS.

I'm not sure how to fix this properly, and whether it's even worth
fixing up properly, but one option (if it's deemed useful, personally
this might be beyond the point of diminishing returns already) might
be using more normative references to the abovementioned specs, and
making this spec as barebones as reasonable.


It has been at least a year since I last looked at this, and only
skimming now, two comments:

4.3.  Allocation of Source-Specific Multicast Addresses

The SSM destination address is reserved, and a system MUST
NOT send a datagram with a destination address of

==> this seems bogus and should probably be removed.  We don't
restrict hosts from sending packets to address, or a
number of other clearly invalid addresses either, but this seems to be
wrong place to specify that such transmissions must be prevented.
And how would that even be implemented -- should the hosts be able to
send packets to using raw sockets?

As a suggestion, just say:

The SSM destination address is reserved, and it must not be
used as a destination address.


A host operating system SHOULD provide an interface to allow an
application to request a unique allocation of a channel destination
address in advance of a session's commencement, and this allocation
database SHOULD persist across host reboots.

==> a worthy goal, but I don't know any implementation which is
providing such an interface.. well, this stuff can probably be removed
if this spec is ever pushed forward to draft standard..


- there are a large number of improperly used uppercase keywords
- s/RFC2373/RFC3513/

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection