Subject: Re: [core] #216: IANA: get Multicast addresses

From: "core issue tracker" <[email-masked]>
Date: Mon, 17 Sep 2012 06:02:05 -0000

#216: IANA: get Multicast addresses

Changes (by hartke@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Done in coap-10:

    IPv4  -- "All CoAP Nodes" address [TBD1], from the IPv4 Multicast
    Address Space Registry.  As the address is used for discovery that
    may span beyond a single network, it should come from the
    Internetwork Control Block (224.0.1.x, RFC 5771).

    IPv6  -- "All CoAP Nodes" address [TBD2], from the IPv6 Multicast
    Address Space Registry, in the Variable Scope Multicast Addresses
    space (RFC3307).  Note that there is a distinct multicast address
    for each scope that interested CoAP nodes should listen to.

-- 
-----------------------------+-------------------------------------
 Reporter:  cabo@…           |       Owner:  draft-ietf-core-coap@…
     Type:  other technical  |      Status:  closed
 Priority:  major            |   Milestone:  post-WGLC-1
Component:  coap             |     Version:  coap-09
 Severity:  In WG Last Call  |  Resolution:  fixed
 Keywords:                   |
-----------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/core/trac/ticket/216#comment:1>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Tue, 18 Sep 2012 08:44:29 -0000

Comment (by esko.dijk@…):

 Indeed variable-scope IPv6 multicast address seems appropriate, to enable
 both link-local and site-local discovery use cases.

 To allow efficient 6lowpan compression of the multicast address (RFC6282),
 with stateless mode DAM=11 (ff02::GG) compressed down to 8 bits, an
 address in the range ff02::00-ff02::ff should be allocated. Very similar
 to the mDNSv6 entry see http://www.iana.org/assignments/ipv6-multicast-
 addresses

-- 
-----------------------------+-------------------------------------
 Reporter:  cabo@…           |       Owner:  draft-ietf-core-coap@…
     Type:  other technical  |      Status:  new
 Priority:  major            |   Milestone:  post-WGLC-1
Component:  coap             |     Version:  coap-09
 Severity:  In WG Last Call  |  Resolution:
 Keywords:                   |
-----------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/216#comment:1>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Sun, 23 Sep 2012 14:01:52 -0000

Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 This is in practice what the current coap-11 multicast address request in
 the IANA section results in. We would be assigned a variable scope
 multicast IPv6 address. The first unassigned variable scope address is
 ::13d, so we might be assigned for example:

 ff02::13d (link-local scope)
 ff05::13d (site-local scope)

 We can surely request something in the 00-ff range, but I am not sure if
 it will possible to get that.

Ticket URL: <http://tools.ietf.org/wg/core/trac/ticket/216#comment:2>
core <http://tools.ietf.org/core/>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sun, 23 Sep 2012 21:57:31 -0400

Hi Zach,

Thanks, makes sense.  Also as we discussed in Vancouver, I had previously spoken to the IANA folks (when the IANA multicast address request was still in the Group Communications draft) and they had suggested the following to make sure that the multicast address assignment goes smoothly:

Right after WG last call has passed, you should submit the IPv4 and IPv6 multicast request forms to IANA. We will have the expert review the requests and get a pre-approval so that when your document is (hopefully) approved by the IESG, all we will have to do is confirm the actual address assignments with the expert.  We are trying to add something to the proto write-up which asks if expert review (if applicable).  If but the time you get to doing the proto write-up that question is not there, you can just include a note saying the expert review was conducted and what the results were.

Here are the forms you will need:
http://www.iana.org/form/multicast-ipv4

http://www.iana.org/form/multicast-ipv6

Thanks,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of core issue tracker
Sent: Sunday, September 23, 2012 10:02 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [core] #216: IANA: get Multicast addresses

Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 24 Sep 2012 06:17:23 +0000

Hi all,

[Zach]
> We can surely request something in the 00-ff range, but I am not sure if  it will possible to get that.

Looking at the registry it is pretty empty in the 00-ff range. So we for sure should request in that range (given the added 6lowpan compression efficiency). If the request is denied, I would expect a good technical explanation why it's not possible or desirable.

RFC 3307 states that assignment starts at 0x100, but on the other hand mDNSv6 got its 0xfb address in 2005.
And for us there's a very good reason to get the address in the 00-ff range; it can save 4 bytes in the IP header.

Esko

-----Original Message-----
From: Rahman, Akbar [mailto:[email-masked]]
Sent: Monday 24 September 2012 3:58
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Dijk, Esko
Subject: RE: [core] #216: IANA: get Multicast addresses

Hi Zach,

Thanks,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of core issue tracker
Sent: Sunday, September 23, 2012 10:02 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [core] #216: IANA: get Multicast addresses

Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

________________________________
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: Zach Shelby <[email-masked]>
Date: Mon, 24 Sep 2012 09:32:26 +0300

Esko, Akbar,

Good point on the registration form, and yes I agree we have good justification. I will add a ticket for us to remember to make this registration. As we have already been through WGLC, this would be a good time to start the process. Would either one of you be willing to fill out the registration form? The spec authors are pretty busy right now getting the coap-12 release done.

Thanks,
Zach

-- 
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: "core issue tracker" <[email-masked]>
Date: Mon, 24 Sep 2012 08:33:11 -0000

Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/216#comment:4>
core <http://tools.ietf.org/core/>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 24 Sep 2012 10:02:03 -0400

Hi Zach,

Yes, Esko and I will take the action to fill out the registration form.

Thanks,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Zach Shelby
Sent: Monday, September 24, 2012 2:32 AM
To: Dijk, Esko
Cc: [email-masked]; core issue tracker; Core WG
Subject: Re: [core] #216: IANA: get Multicast addresses

Esko, Akbar,

Good point on the registration form, and yes I agree we have good
justification. I will add a ticket for us to remember to make this
registration. As we have already been through WGLC, this would be a good
time to start the process. Would either one of you be willing to fill
out the registration form? The spec authors are pretty busy right now
getting the coap-12 release done.

Thanks,
Zach

On Sep 24, 2012, at 9:17 AM, Dijk, Esko wrote:

> Looking at the registry it is pretty empty in the 00-ff range. So we
for sure should request in that range (given the added 6lowpan
compression efficiency). If the request is denied, I would expect a good
technical explanation why it's not possible or desirable.
> And for us there's a very good reason to get the address in the 00-ff
range; it can save 4 bytes in the IP header.
> Cc: [email-masked]; [email-masked];
[email-masked]; Dijk, Esko
> Thanks, makes sense.  Also as we discussed in Vancouver, I had
previously spoken to the IANA folks (when the IANA multicast address
request was still in the Group Communications draft) and they had
suggested the following to make sure that the multicast address
assignment goes smoothly:
> 
> Right after WG last call has passed, you should submit the IPv4 and
IPv6 multicast request forms to IANA. We will have the expert review the
requests and get a pre-approval so that when your document is
(hopefully) approved by the IESG, all we will have to do is confirm the
actual address assignments with the expert.  We are trying to add
something to the proto write-up which asks if expert review (if
applicable).  If but the time you get to doing the proto write-up that
question is not there, you can just include a note saying the expert
review was conducted and what the results were.
> Changes (by zach@...):
> Reporter:  cabo@...           |       Owner:  draft-ietf-core-coap@...
> 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.