Subject: Re: [core] Scalability of multicast use for discovery (ticket #247)

From: Zach Shelby <[email-masked]>
Date: Fri, 2 Nov 2012 11:20:45 +0200

Coming back to the solution for this ticket. I would like to propose the following in the WG meeting next week:

1. Change the IPv4 request to the Local Network Control Block. Although we could ask for the Ad-Hoc Block I think Local Network is sufficient for our discovery needs in IPv4.
2. Change the IPv6 request to link-local and site-local scope only. Here we need site-local scope due to the way 6LoWPAN networks are typically built. 
3. Recommend the use application specific multicast addresses for larger scope multicast needs.

Regarding the security consideration, with these changes I think the existing text in 11.4 is sufficient. 

If this is OK with the WG, then we can make the needed changes in -13 and then update our IANA registration request accordingly. 

Zach

On Oct 18, 2012, at 10:27 AM, Dijk, Esko wrote:

> I agree, since the CoRE discovery use cases seem to be all for link-local or site-local scope multicast.
> 
> For the IPv4 address assignment, there's no site-local IPv4 but looking at the IANA registry (http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml#multicast-addresses-3 ) it looks somewhat like the ad-hoc block I (224.0.2.0 - 224.0.255.255) has taken on this function? Since there are some recent additions of single addresses in there.
> Alternatively we only register link-local for IPv4.
> 
> Esko
> 
> -----Original Message-----
> From: Zach Shelby [mailto:[email-masked]] 
> Sent: Thursday 18 October 2012 9:05
> To: Dijk, Esko
> Cc: [email-masked]
> Subject: Re: [core] Scalability of multicast use for discovery (ticket #247)
> 
> Esko,
> 
> On Oct 18, 2012, at 9:07 AM, Dijk, Esko wrote:
> 
>> Dear all,
>> 
>> to explore possible solutions to ticket #247 (http://trac.tools.ietf.org/wg/core/trac/ticket/247) in the WG here are some initial ideas.
>> 
>> To enable safe use of multicast for CoAP discovery; we could include in core-coap stricter requirements on multicast responding e.g.:
>> 
>> - for site-local scope or any smaller scope, a discovery multicast request (/.well-known/core) by an unauthenticated client MAY be responded to by a server
>> - for organization-local and global scope, a discovery multicast request by an unauthenticated client SHOULD NOT be responsed to
>> - for global scope, a discovery multicast request SHOULD NOT be responded to. Exception case is a server known to be deployed in an isolated network i.e. multicast not propagating onto the internet or to multicast backbones. In that case the server MUST be explicitly configured to do so.
> 
> This is not just about discovery, but for responding to any multicast CoAP request. 
> 
> I start to be doubtful about the actual utility of the CoAP multicast address with global scope (the risks are much greater than the benefit). To be safer, and deal with the IANA comments completely, we could just limit the default CoAP multicast address to local and site-local scope only. For specialized applications where global scope could be useful, it would be better for that application to use a dedicated multicast address for that purpose. 
> 
> Zach
> 
>> This would allow local multicast discovery (of servers previously unknown to the client) use cases without the side effects that the IANA appointed expert mentions.
>> 
>> regards,
>> Esko
>> 
>> 
>> Esko Dijk
>> 
>> Philips Group Innovation, Research
>> High Tech Campus 34, Eindhoven, The Netherlands
>> [email-masked]
>> 
>> 
>> 
>> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
>> _______________________________________________
>> core mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/core
> 
> -- 
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://www.sensinode.com
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
> 
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Antonio Jara <[email-masked]>
Date: Fri, 02 Nov 2012 11:52:22 +0100

Hi Zach,

Maybe, it could be interesting to ask also to IANA some predefinition  
of multicast addresses for CoAP devices:

Variable scope to find all the CoAP devices (similar to other  
technologies e.g. BACnet).
1- CoAP // e.g. FF0X:0:0:0:0:0:0:C0A7

Note that, it s is also considering the local and site scopes:
1- Local CoAP Devices // e.g. FF02:0:0:0:0:0:0:C0A7
2- Site CoAP Devices // e.g. FF05:0:0:0:0:0:0:C0A7

7 is because looks like "P" in HEX.

In addition, it could be considered the options for CoAP RD.
1- Local CoAP Resource Directories (Browsing) // e.g. FF02:0:0:0:0:0:0:C0AB
2- Site CoAP Resource Directories (Browsing) // e.g. FF05:0:0:0:0:0:0:C0AB

B is because the browsing, commonly used in mDNSv6 (FB).

Best regards,
Antonio J. Jara

Quoting Zach Shelby <[email-masked]>:

> Coming back to the solution for this ticket. I would like to propose  
> the following in the WG meeting next week:
>
> 1. Change the IPv4 request to the Local Network Control Block.  
> Although we could ask for the Ad-Hoc Block I think Local Network is  
> sufficient for our discovery needs in IPv4.
> 2. Change the IPv6 request to link-local and site-local scope only.  
> Here we need site-local scope due to the way 6LoWPAN networks are  
> typically built.
> If this is OK with the WG, then we can make the needed changes in  
> -13 and then update our IANA registration request accordingly.
>
> Zach
>
>> I agree, since the CoRE discovery use cases seem to be all for  
>> link-local or site-local scope multicast.
>>
>> For the IPv4 address assignment, there's no site-local IPv4 but  
>> looking at the IANA registry  
>> (http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml#multicast-addresses-3 ) it looks somewhat like the ad-hoc block I (224.0.2.0 - 224.0.255.255) has taken on this function? Since there are some recent additions of single addresses in  
>> there.
>>> to explore possible solutions to ticket #247  
>>> (http://trac.tools.ietf.org/wg/core/trac/ticket/247) in the WG  
>>> here are some initial ideas.
>>>
>>> To enable safe use of multicast for CoAP discovery; we could  
>>> include in core-coap stricter requirements on multicast responding  
>>> e.g.:
>>>
>>> - for site-local scope or any smaller scope, a discovery multicast  
>>> request (/.well-known/core) by an unauthenticated client MAY be  
>>> responded to by a server
>>> - for organization-local and global scope, a discovery multicast  
>>> request by an unauthenticated client SHOULD NOT be responsed to
>>> - for global scope, a discovery multicast request SHOULD NOT be  
>>> responded to. Exception case is a server known to be deployed in  
>>> an isolated network i.e. multicast not propagating onto the  
>>> internet or to multicast backbones. In that case the server MUST  
>>> be explicitly configured to do so.
>>
>> I start to be doubtful about the actual utility of the CoAP  
>> multicast address with global scope (the risks are much greater  
>> than the benefit). To be safer, and deal with the IANA comments  
>> completely, we could just limit the default CoAP multicast address  
>> to local and site-local scope only. For specialized applications  
>> where global scope could be useful, it would be better for that  
>> application to use a dedicated multicast address for that purpose.
>>
>> Zach
>>
>>> This would allow local multicast discovery (of servers previously  
>>> unknown to the client) use cases without the side effects that the  
>>> IANA appointed expert mentions.
>>>
>>> regards,
>>> Esko
>>>
>>>
>>> Esko Dijk
>>>
>>> The information contained in this message may be confidential and  
>>> legally protected under applicable law. The message is intended  
>>> solely for the addressee(s). If you are not the intended  
>>> recipient, you are hereby notified that any use, forwarding,  
>>> dissemination, or reproduction of this message is strictly  
>>> prohibited and may be unlawful. If you are not the intended  
>>> recipient, please contact the sender by return e-mail and destroy  
>>> all copies of the original message.

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 13 Nov 2012 10:53:44 +0000

Hi Antonio,

what we will first try is to get an allocation in the 0x0-0xFF group which would help save some bytes in 6LoWPAN link-local use. So it could be, skipping the last 2 characters:
 FF0x::C0

if that's not allowed for some reason, we could ask for C0A7.
The usage of scopes may be restricted in the way Zach proposes.

Esko

-----Original Message-----
From: Antonio Jara [mailto:[email-masked]]
Sent: Friday 2 November 2012 11:52
To: Zach Shelby
Cc: Dijk, Esko; [email-masked]
Subject: Re: [core] Scalability of multicast use for discovery (ticket #247)

Hi Zach,

Best regards,
Antonio J. Jara

>>> all copies of the original message.

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Antonio Jara <[email-masked]>
Date: Tue, 13 Nov 2012 11:59:04 +0100

Hi Esko,

This sounds perfect for me.

Checking the IANA assignment this does not look  assigned. Therefore,  
it should not be any problem.

http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml

Best regards and thanks,
Antonio J. Jara

Quoting "Dijk, Esko" <[email-masked]>:

> Hi Antonio,
>
> what we will first try is to get an allocation in the 0x0-0xFF group  
> which would help save some bytes in 6LoWPAN link-local use. So it  
> could be, skipping the last 2 characters:
>  FF0x::C0
>
> solely for the addressee(s). If you are not the intended recipient,  
> you are hereby notified that any use, forwarding, dissemination, or  
> reproduction of this message is strictly prohibited and may be  
> unlawful. If you are not the intended recipient, please contact the  
> sender by return e-mail and destroy all copies of the original  
> message.
>
>