Re: [MBONED] draft-ietf-v6ops-cpe-simple-security-12.txt feedback

[Tim Chown <tjc@ecs.soton.ac.uk>]

Hi,

I agree that 3.1 REC-2 should say site-local scope is the default for the context of this draft (CPE devices in homes and small offices).   The provider would most likely use organisation-local to scope multicast within its whole network.

In our campus site-local multicast is constrained by configured router boundaries within departments and organisation-local scope multicast is constrained within our campus.   But that's a very different, larger scenario.

The terminology is different for unicast where if we used 'site local' unicast ULAs we would use one /48 ULA for our whole campus.    As of yet we have not felt a need to multi-address (any part of) our campus with ULAs.

Tim

On 28 Jul 2010, at 08:51, Toerless Eckert wrote:

> For once, the dfraft in question does not differentiate between
> unicast site-local and multicast site-local addresses, and i do not
> even know if there are unicast orginaizational-local addresses.
> 
> I am only referring to scoped IPv6 multicast group addresses as
> defined in RFC4291 section 2.7. IPv6 site-local IP multicast addresses
> are just a smaller scope than IPv6 Organizational-Local scope. There
> is otherwise no semantic difference between them.
> 
> Routed IP multicast works and can be recommended and should be included,
> i did not contest that. I contested that we do recommend the correct scope
> size in this draft. Organizational-Local is too large, and i think i explained
> the risks.
> 
> Thanks
>    Toerless
> 
> On Wed, Jul 28, 2010 at 09:40:29AM +0200, Fred Baker wrote:
>> I'm copying the IESG, as this document is currently under review in the IESG. Having been through, literally, years of conversation and multiple last calls, I'm a little concerned that this request to reconsider and redraft the recommendations of the specification is coming so late.
>> 
>> We have had this in review for the past few years, and I for one have also commented that the only multicast models that we actually have algorithms to implement are link-local (broadcast on a directly-attached LAN) and routed IP multicast; this is the reason that the concept of multi-subnet broadcast was removed from RFC 1716 in the process of editing into RFC 1812. Organization-local addressing has inexplicably survived in the IPv6 Addressing Architecture, although the lack of running code re its routing has been pointed out on numerous occasions. The argument in the discussion was that since 6man is deluded into believing that a form of multicast besides link-local and routed exists and is workable, it should be dealt with.
>> 
>> In my opinion, not as working group chair but as an individual who knows a little about such things, 6man should either be asked to define the term ("organization-local multicast is a form of routed multicast in which administrative boundaries are observed") and demonstrate algorithms and running code that systemically imposes such boundaries. Note that RFC 2365 defines administratively scoped multicast for IPv4, but does not touch on IPv6 and provides no algorithms to deal with the obvious "security consideration" of a systemic boundary to such routing.
>> 
>> On Jul 28, 2010, at 9:23 AM, Toerless Eckert wrote:
>> 
>>> I would strongly suggest to change the requirement in REC-2 of
>>> subject draft to say that the default SHOULD be site-local scope
>>> instead of organizational-local scope.
>>> 
>>> The reason for this is that the largest scope that we specify in this draft
>>> will influence designers of ip multicast applications that use ASM multicast.
>>> The worst of such often written applications are using ASM multicast for
>>> discovery. When these applications are then deployed in other environments
>>> such as enterprises, they will send out IP multicast packets that will
>>> go across the whole organization, which in the case of an enterprise could
>>> be worldwide.
>>> 
>>> On the other hand, use of ASM to do this type of discovery mechanisms
>>> in applications, while not preferred by multicast architecture, is 
>>> perfectly valid for simple applications meant to run in a residential home.
>>> 
>>> So the best compromise seems to be to recommend the smallest scope we
>>> feel is large enough for a residential (or small business) site, and
>>> that would be site-local scope.
>>> 
>>> [ Now if it was for me, i would add the requirement that the scope must not
>>> be larger than site-local scope to be within the bounds of the drafts
>>> recommendations].
>>> 
>>> I have not followed the draft in detail in before, so if there where any
>>> arguments to recommend organizational scope, it would be nice if those
>>> could be repeated.
>>> 
>>> I have Cc'ed mboned, because my concern is one of multicast operations,
>>> and i am not aware that these considerations where brought up in front of
>>> mboned in before.
>>> 
>>> Thanks
>>>   Toerless
>> 
>> http://www.ipinc.net/IPv4.GIF
> 
> -- 
> ---
> Toerless Eckert, eckert@cisco.com
> Cisco NSSTG Systems & Technology Architecture
> "The strategy is what you do, not what you write" - Wesley Clark
> "Vision without ressources is hallucination" - James L. Jones
> 
> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned