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" <esko.dijk@philips.com>:

> 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:jara@um.es]
> Sent: Friday 2 November 2012 11:52
> To: Zach Shelby
> Cc: Dijk, Esko; core@ietf.org
> Subject: Re: [core] Scalability of multicast use for discovery (ticket #247)
>
> 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 <zach@sensinode.com>:
>
>> 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:zach@sensinode.com]
>>> Sent: Thursday 18 October 2012 9:05
>>> To: Dijk, Esko
>>> Cc: core@ietf.org
>>> 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
>>>> esko.dijk@philips.com
>>>>
>>>>
>>>>
>>>> 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
>>>> core@ietf.org
>>>> 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
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>
>
>
> ________________________________
> 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.
>
>