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

[Brian Haberman <bkhabs@nc.rr.com>]

Hugh Holbrook wrote:
> [ ... Snipping just the thread on scoping for ssm ]
> 
> My comments inline...
> 
> 
>>Date: Mon, 10 Mar 2003 08:01:49 -0500
>>From: Brian Haberman <bkhabs@nc.rr.com>
>>Cc: Hugh Holbrook <holbrook@cisco.com>, ssm@ietf.org
>>
>>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?
> 

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.

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

I am ok with it, but I didn't raise the issue either.  So, I would
like Pekka's assessment before we declare victory. :)

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

> 
> 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.  Should we add a reference to RFC
3484 as a note on how the address selection could occur?

Brian

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