[ssm] what to say about scoping for v6 [was ...last call...]

[Hugh Holbrook <[e-mail]>]

[ ... Snipping just the thread on scoping for ssm ]

My comments inline...

> Date: Mon, 10 Mar 2003 08:01:49 -0500
> From: Brian Haberman <[e-mail]>
> Cc: Hugh Holbrook <[e-mail]>, [e-mail]
> 
> Pekka Savola wrote:
> > On Sun, 9 Mar 2003, Brian Haberman wrote:
> > 
> >>>   The scope of the unicast-prefix based multicast address MUST NOT
> >>>   exceed the scope of the unicast prefix embedded in the multicast
> >>>   address.
> >>>
> >>>note: "embedded in the multicast address".  But as you should note here, 
> >>>an address (particularly _SSM_, which is really not derived from the 
> >>>unicast prefix) does not.
> >>
> >>The intent was that the scope of the SSM group address would
> >>not exceed the scope of the SSM source address.  The scoped addr
> >>arch forwarding rules *WILL* prevent a scoped address from leaking
> >>out of the administrative zone.
> >>
> >>The overall issue though is not SSM-specific.  
> > 
> > 
> > Yes and no: in ASM, the DR only checks that G is ok; not it must check 
> > that both S and G are ok.
> > 
> 
> Actually, the DR has to check both S and G to ensure that it does
> not send a PIM Join across a scope zone boundary regardless of it
> being ASM or SSM.  There was some text in the original PIM for v6
> draft a long time ago.
> 
> > 
> >>That is, the
> >>scoped addr arch is responsible for determining the forwarding
> >>issues around scoped addresses.  I don't see a need for putting
> >>any type of scoped address issues in the SSM doc.
> > 
> > ...
> > 
> >>As stated above, I don't see a reason to deal with scoped addresses
> >>in the SSM arch doc.
> > 
> > 
> > I understand this argument and I agree with it, mostly: at this point, we
> > may end up doing some nasty things (in ipv6 w.g.) with scoped address
> > architecture anyway, so trying to specify everything in detail in the 
> > specs before we know we have to do it seems premature.
> 
> Agreed. :)
> 
> > 
> > So, I can support putting considerations like these in the scoped address 
> > architecture document, but IMO, there *must* be a brief mention of the 
> > issues and a pointer in e.g. Security Considerations section.
> > 

A pointer to what? draft-ietf-ipngwg-scoping-arch-04.txt?

> I don't see a problem with doing that.  The security section can mention
> the issue and say that it is out of scope for this doc and is being
> addressed elsewhere.

So I'm trying to convert this discussion about scoping to concrete
text.  Here's what the doc currently says about v6 scoped addresses.

  For IPv6, administratively scoped SSM addresses are created by choosing
  an appropriate scope identifier for the SSM destination address.  Normal
  IPv6 multicast scope boundaries are applied to traffic sent to an SSM
  destination address.

I note that this paragraph is confusing because it says you can make a
"scoped SSM addresses" when what it should say is "scoped SSM channel
addresses".  Here is proposed text to incorporate what I think Pekka
is suggesting.

  For IPv6, administratively scoped SSM channel addresses are created
  by choosing an appropriate scope identifier for the SSM destination
  address.  Normal IPv6 multicast scope boundaries are applied to
  traffic sent to an SSM destination address, including any relevant
  boundaries applied to both the source and destination address.

Question 1: Do you accept the above text?  I'm not sure I captured the
issue, so I'd appreciate a better alternative if you see one.

Question 2: If not, is there an appropriate reference for "Normal IPv6
multicast scope boundaries," or is it preferable to intentionally
leave the document without a reference?

Question 3: Should we add text to clarify the "embedded address" text
in RFC3306.  I can think of three options:

Either prohibit it:

  For IPv6, senders MUST ensure that the scope of a channel
  destination address does not exceed the scope of the channel source
  address.

Or allow it:

  For IPv6, the scope of a channel destination address MAY exceed the
  scope of the channel source address.  Normal forwarding rules for
  scoped traffic apply to a packet sent to such a channel.  Normal
  multicast scoping rules apply for any routing protocol messages
  (e.g., "joins") referring to such a channel.

Or say nothing:

I am inclined to do the latter, and I think this is what both of you
are saying.  Am I right?

> >>>>As stated above RFC 3306 does have restrictions on what the scope
> >>>>of the group address can be.
> >>>
> >>>
> >>>As above, I'm not sure how this applies to RFC3306 addresses which do not 
> >>>depend on the prefix, ie. SSM.
> >>
> >>I consider the source address of an SSM group to be equivalent to
> >>the unicast prefix used in an RFC 3306 generated address.
> > 
> > 
> > One could consider so, but as was noted earlier, I didn't see it that way, 
> > and many others probably won't either -- unless clarified.
> > 
> > More work for scoped addrarch, I suppose.
> > 
> 
> Long-term it should be fixed in a revision of 3306.  Near-term we
> could add text to this doc in section 4.3 clarifying the allocation
> issue on scopes.
> 
> > 
> >>>>Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with
> >>>>permanently allocated IPv6 multicast addresses.  This is for
> >>>>consistency with permanent IPv4 multicast addresses.  That
> >>>>means that T=0 in the flags field.  I would expect that SSM
> >>>>applications would allocate group IDs out of the 0x80000000 to
> >>>>0xFFFFFFFF range for SSM channels.
> >>>
> >>>But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue 
> >>>that the reservation does not hold.
> >>
> >>Not sure what you mean here.  3307 is very explicit in what IANA
> >>is reserving for group IDs.
_______________________________________________
ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm