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

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 11 Mar 2003, Brian Haberman wrote:
> > A pointer to what? draft-ietf-ipngwg-scoping-arch-04.txt?
> > 
> 
> That would be the beast.  RFC 3484 references it when discussing
> the issue of scope within the source address selection policy.  It
> can be an informative reference here.

Agree.

> > 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.
> 
> I am ok with it, but I didn't raise the issue either.  So, I would
> like Pekka's assessment before we declare victory. :)

I can live with it, with the inclusion of the reference.

However, I'd like a statement in the security considerations, perhaps 
along the lines of:

One should note that the use of IPv6 scoped addresses either in S or G may
cause significant complexities, for example regarding mismatching scopes
between S and G or regarding forwarding decisions for a scoped (S,G).  
The implications of scoped addresses are described in other documents
[REF:SCOPED-ARCH]

> > 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?
> 
> I don't see a problem with having an informative reference for the
> scoped addr arch doc.

I think an informational reference is necessary. (Actually, it should be 
"almost" normative, but we don't want to have SSM arch get stuck due to 
scoped addrarch, so..)

> > 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?
> 
> I agree, the latter works for me.  

I'm ok with leaving the text out.  It is up to RFC3306bis and 
clarification of it in scoped addrarch.

> Should we add a reference to RFC
> 3484 as a note on how the address selection could occur?

I'm ok with it but don't see where it would fit nicely.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings





_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm