Subject: [core] Simple registration and URI length restrictions

From: Stuart Longland <[email-masked]>
Date: Wed, 25 Oct 2017 17:49:33 +1000

Hi all,

I'm in the process of writing a proof-of-concept implementation of the
CoRE resource discovery server for the purpose of allowing devices on a
Thread/6LoWPAN network to "log in".

Reading the spec, and taking into account the limitations of the devices
we're using (built around TI's CC2538 and running the OpenThread
firmware stack), I figured the Simple publishing mechanism would be the
easiest to implement as I already have the /.well-known/core endpoint
working on the devices (it just coughs up static output).

For simplicity's sake, I was going to use the EUI64 of the device as the
endpoint name.

The problem seems to be the size of the URI this generates, the spec says¹:
> 5.3.2.  Simple publishing to Resource Directory Server
> 
>    An endpoint that wants to make itself discoverable occasionally sends
>    a POST request to the "/.well-known/core" URI of any candidate
>    directory server that it finds.  The body of the POST request is
>    empty, which triggers the resource directory server to perform GET
>    requests at the requesting server's default discovery URI to obtain
>    the link-format payload to register.
> 
>    The endpoint MUST include the endpoint name and MAY include the
>    registration parameters d, lt, and et, in the POST request as per
>    Section 5.3.
> 
>    The following example shows an endpoint using simple publishing, by
>    simply sending an empty POST to a resource directory.
> 
>    Req:(to RD server from [ff02::1])
>    POST coap://rd.example.com/.well-known/core?lt=6000;ep=node1

I'm testing this with the OpenThread CLI, and I've discovered that it
limits URIs to 32 characters.  This means my endpoint name gets chopped
off.  This is the outgoing request:

>> coap post fdde:ad00:beef:0:52c2:9f9e:6e6d:ade1 .well-known/core?ep=11f47b5800124b00&lt=300
> Sending coap request: Done

and my server (implemented with node-coap) sees this:
> [2017-10-25T07:27:50.017Z]  INFO: WideSkyCoAPGateway/coap/10134 on vk4msl-ws: Begin request (method=POST, uri=/.well-known/core?ep=11f47b58001)
>     source: {
>       "address": "fdde:ad00:beef::ff:fe00:ec00",
>       "family": "IPv6",
>       "port": 5683,
>       "size": 39
>     }

I can change this in OpenThread of course, I've identified where the
changes would need to go, however the other examples use the much
shorter `/rd` endpoint, which avoids some of these problems.  I was
wondering whether it was actually intended that `/.well-known/core` be
used or whether this was overlooked?

Regards,
-- 
     _ ___             Stuart Longland - Systems Engineer
\  /|_) |                           T: +61 7 3535 9619
 \/ | \ |     38b Douglas Street    F: +61 7 3535 9699
   SYSTEMS    Milton QLD 4064       http://www.vrt.com.au

1.
https://tools.ietf.org/html/draft-ietf-core-resource-directory-11#section-5

---

From: Esko Dijk <[email-masked]>
Date: Wed, 25 Oct 2017 08:52:34 +0000

Hello Stuart,

In general the problem in OpenThread CLI code should be fixed anyhow, because you can never know at which URI people will host their RD. It may be very long! Especially when OpenThread code ends up into products it needs to be right.

Still a good question I think, because the current draft states that an endpoint first discovers RD(s) and then publishes itself (using the Section 5.3.2 POST approach) to one or more selected RD(s). Since the endpoint already did the discovery, it knows the resource at which the RD service resides (e.g. /rd). So why doesn't it use that resource /rd to publish itself? That's the RD where the device wants to register.

One valid reason to still use /.well-known/core is the fact that sometimes only the IPv6 address, or an IPv6 hostname, of the RD can be distributed in a network using specific means. E.g. https://tools.ietf.org/html/draft-ietf-core-resource-directory-11#section-9.2 states how an ND option can do this. In some deployments it may be a well-known anycast IP address pointing to the nearest RD. In these cases the client doesn't know (yet) the specific resource to contact the RD, so using a well-known resource helps to overcome this issue.   Of course the endpoint could in principle unicast discover the RD resource at coap://[RD-IPv6-address]/.well-known/core?rt=core.rd , but that would add more complexity to the endpoint and more data traffic.  I assume this "keep the endpoint simple" was the reason to use a well-known URI.

** Note for RD editors
I assume multicast POSTing to multiple RDs is not supported even though Section 5.3.2 uses a multicast address [ff02::1] in the example. (This seems wrong here?).
Also in the current draft the difference between Simple Registration 5.3.1 and Simple Publishing 5.3.2 is not clear. (They appear different mechanisms, but when looking closer they appear the same mechanism...) RD-08 for example makes more clear that these are one and the same process. Let's give these two one name then?

Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Stuart Longland
Sent: Wednesday, October 25, 2017 09:50
To: [email-masked] WG ([email-masked]) <[email-masked]>
Subject: [core] Simple registration and URI length restrictions

Hi all,

I'm in the process of writing a proof-of-concept implementation of the CoRE resource discovery server for the purpose of allowing devices on a Thread/6LoWPAN network to "log in".

Reading the spec, and taking into account the limitations of the devices we're using (built around TI's CC2538 and running the OpenThread firmware stack), I figured the Simple publishing mechanism would be the easiest to implement as I already have the /.well-known/core endpoint working on the devices (it just coughs up static output).

For simplicity's sake, I was going to use the EUI64 of the device as the endpoint name.

I'm testing this with the OpenThread CLI, and I've discovered that it limits URIs to 32 characters.  This means my endpoint name gets chopped off.  This is the outgoing request:

>> coap post fdde:ad00:beef:0:52c2:9f9e:6e6d:ade1
>> .well-known/core?ep=11f47b5800124b00&lt=300

>       "address": "fdde:ad00:beef::ff:fe00:ec00",

I can change this in OpenThread of course, I've identified where the changes would need to go, however the other examples use the much shorter `/rd` endpoint, which avoids some of these problems.  I was wondering whether it was actually intended that `/.well-known/core` be used or whether this was overlooked?

Regards,

1.

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

________________________________
The information contained in this email may be confidential and/or 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 email 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 email.

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 25 Oct 2017 11:30:43 +0200

Hello Stuart,

> used or whether this was overlooked?

The short `/rd` is only an example and needs to be discovered using the
discovery steps unless Simple Registration is performed. It is up to the
resource directory to pick its own path, which may be as short as `/rd`
or even longer than `.well-known/core`.

Registration without the URI discovery steps (ie. Simple Registraition,
which sounds very suitable for the use case you decribe) can only happen
to a .well-known URI, or it would enforce a particular path design on
the server.

I recommend to increase the limit of the URI length; as long as you
statically know the ep name length and use Simple Registration, you can
be sure that even a short (but longer than 32 bytes) length it
sufficient, as opposed to URI discovery where you'd need to be prepared
to process much longer URIs.

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 26 Oct 2017 08:47:42 +0200

Hello Esko,

On Wed, Oct 25, 2017 at 08:52:34AM +0000, Esko Dijk wrote:
> I assume multicast POSTing to multiple RDs is not supported even
> though Section 5.3.2 uses a multicast address [ff02::1] in the
> example. (This seems wrong here?).

The multicast address was used erroneously in that example; the upcoming
next draft version fixes that.

> Also in the current draft the difference between Simple Registration
> 5.3.1 and Simple Publishing 5.3.2 is not clear. (They appear different
> mechanisms, but when looking closer they appear the same mechanism...)
> RD-08 for example makes more clear that these are one and the same
> process. Let's give these two one name then?

Only one mechanism is meant. Good point, thanks, taken up on the issue
tracker[1].

Best regards
Christian

[1]: https://github.com/core-wg/resource-directory/issues/75

---

From: Stuart Longland <[email-masked]>
Date: Thu, 26 Oct 2017 17:22:08 +1000

On 25/10/17 18:52, Esko Dijk wrote:
> In general the problem in OpenThread CLI code should be fixed anyhow,
> because you can never know at which URI people will host their RD. It
> may be very long! Especially when OpenThread code ends up into
> products it needs to be right.

This is true, especially if it's actually implemented as a HTTP service
on the other side of a proxy.  (I'd hope not, but you never know.)

I have in fact, amended OpenThread to cope with this:
https://github.com/vrtsystems/openthread/commit/fd8b6fd2460f2abbbf2318f17d3848742ff15009

I'll raise it with them on their mailing list and see about making this
configurable in the sources (I'm thinking a #define).  Thankfully it
doesn't appear to be a limitation of the underlying CoAP client.

> Still a good question I think, because the current draft states that
> an endpoint first discovers RD(s) and then publishes itself (using
> the Section 5.3.2 POST approach) to one or more selected RD(s). Since
> the endpoint already did the discovery, it knows the resource at
> which the RD service resides (e.g. /rd). So why doesn't it use that
> resource /rd to publish itself? That's the RD where the device wants
> to register.

Well, that's why I wondered if there was an omission here.  I could see
good reasons for using `.well-known/core`, but it also made me wonder if
a suitable half-way compromise could be used.

Arguably there's nothing stopping me from breaking out my function that
replies to `.well-known/core` with the list of endpoints and calling
that to generate the `POST` payload when registering if I'm going to do
it the long way. :-)

> One valid reason to still use /.well-known/core is the fact that
> sometimes only the IPv6 address, or an IPv6 hostname, of the RD can
> be distributed in a network using specific means. E.g.
> https://tools.ietf.org/html/draft-ietf-core-resource-directory-11#section-9.2
> states how an ND option can do this. In some deployments it may be a
> well-known anycast IP address pointing to the nearest RD. In these
> cases the client doesn't know (yet) the specific resource to contact
> the RD, so using a well-known resource helps to overcome this issue.

So if a device doesn't know a target address, I'm guessing the anycast
IP address is the intended mechanism by which to perform service
publication?

> ** Note for RD editors I assume multicast POSTing to multiple RDs is
> not supported even though Section 5.3.2 uses a multicast address
> [ff02::1] in the example. (This seems wrong here?). Also in the
> current draft the difference between Simple Registration 5.3.1 and
> Simple Publishing 5.3.2 is not clear. (They appear different
> mechanisms, but when looking closer they appear the same
> mechanism...) RD-08 for example makes more clear that these are one
> and the same process. Let's give these two one name then?

Is it particularly harmful to do a POST to a multicast address?
Presumably the other nodes not set up as RD could just ignore the POST.

I was planning to have the nodes POST to
coap://[ff05::fd]/.well-known/core… at the moment I'm just unicasting it
as I'm finding `node-coap` a little reluctant to join multicast IPv6 groups.

The intricacies of multicast programming is something I'm still just
getting my head around, and in the IPv6 context in particular; while
I've been experimenting with it privately at home, this has largely been
unicast communications.

I'll have a look at using anycast addresses, see if that offers a viable
solution too.  I don't want to hard-code addresses if I can avoid it. :-)

Many thanks.
Regards,

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Oct 2017 09:26:20 +0200

> IP address is the intended mechanism by which to perform service

We have recently cleaned up the section "Finding a Resource Directory”.

https://core-wg.github.io/resource-directory/draft-ietf-core-resource-directory.html#rfc.section.4

Please let us know whether that works for you.

Grüße, Carsten

---

From: Esko Dijk <[email-masked]>
Date: Thu, 26 Oct 2017 13:51:59 +0000

Carsten,

The cleanup looks good - though the multicast discovery example states

coap://[ff02::1]/.well-known/core?rt=core.rd*

But I would suggest a better practice is one of below with "All CoAP Nodes" address

- coap://[ff02::fd]/.well-known/core?rt=core.rd
- For (mesh) network technologies that define the realm-local scope: coap://[ff03::fd]/.well-known/core?rt=core.rd
- RFC7252 suggests that scope 5 is also supported, so this can also be done:   coap://[ff05::fd]/.well-known/core?rt=core.rd

The suggestion is also to look for "core.rd" for an endpoint seeking to register, not "core.rd*" which would return possibly many unwanted responses.

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, October 26, 2017 09:26
To: Stuart Longland <[email-masked]>
Cc: Esko Dijk <[email-masked]>; [email-masked] WG ([email-masked]) <[email-masked]>
Subject: Re: [core] Simple registration and URI length restrictions

Grüße, Carsten

---

From: Esko Dijk <[email-masked]>
Date: Thu, 26 Oct 2017 14:12:40 +0000

Hi,

> Presumably the other nodes not set up as RD could just ignore the POST.

I would say the impact of multicast POST /.well-known/core to trigger Simple Registration is about the same as a multicast GET /.well-known/core which may be used for discovering RDs.  It may of course lead to lots of traffic if there are many RDs active, who will each query the endpoint for its resources after receiving the POST.

> I was planning to have the nodes POST to coap://[ff05::fd]/.well-known/core… at the moment I'm just unicasting it

The current RD draft is not really clear on whether an RD will accept a multicast request that POSTs to /.well-known/core.  If we want to rely on that behavior, it should be specified clearly in draft-RD. Normally only resources specifically configured to support multicast will accept a multicast request; other resources will silently ignore the request. See e.g. https://tools.ietf.org/html/rfc7390#section-2.7 that summarizes the requirements. I would assume that supporting multicast GET for a resource (like /.well-known/core) doesn't imply that multicast-POST is necessarily supported...?   In case we like to support such multicast, then we should list a unicast example for Simple Registration and a multicast example for it.

Esko

-----Original Message-----
From: Stuart Longland [mailto:[email-masked]]
Sent: Thursday, October 26, 2017 09:22
To: Esko Dijk <[email-masked]>; [email-masked] WG ([email-masked]) <[email-masked]>
Subject: Re: [core] Simple registration and URI length restrictions

> products it needs to be right.

This is true, especially if it's actually implemented as a HTTP service on the other side of a proxy.  (I'd hope not, but you never know.)

I'll raise it with them on their mailing list and see about making this configurable in the sources (I'm thinking a #define).  Thankfully it doesn't appear to be a limitation of the underlying CoAP client.

> an endpoint first discovers RD(s) and then publishes itself (using the
> Section 5.3.2 POST approach) to one or more selected RD(s). Since the
> endpoint already did the discovery, it knows the resource at which the
> RD service resides (e.g. /rd). So why doesn't it use that resource /rd
> to publish itself? That's the RD where the device wants to register.

Well, that's why I wondered if there was an omission here.  I could see good reasons for using `.well-known/core`, but it also made me wonder if a suitable half-way compromise could be used.

Arguably there's nothing stopping me from breaking out my function that replies to `.well-known/core` with the list of endpoints and calling that to generate the `POST` payload when registering if I'm going to do it the long way. :-)

> sometimes only the IPv6 address, or an IPv6 hostname, of the RD can be
> distributed in a network using specific means. E.g.
> https://tools.ietf.org/html/draft-ietf-core-resource-directory-11#sect
> ion-9.2 states how an ND option can do this. In some deployments it
> may be a well-known anycast IP address pointing to the nearest RD. In
> these cases the client doesn't know (yet) the specific resource to
> contact the RD, so using a well-known resource helps to overcome this
> issue.

So if a device doesn't know a target address, I'm guessing the anycast IP address is the intended mechanism by which to perform service publication?

I was planning to have the nodes POST to coap://[ff05::fd]/.well-known/core… at the moment I'm just unicasting it as I'm finding `node-coap` a little reluctant to join multicast IPv6 groups.

The intricacies of multicast programming is something I'm still just getting my head around, and in the IPv6 context in particular; while I've been experimenting with it privately at home, this has largely been unicast communications.

I'll have a look at using anycast addresses, see if that offers a viable solution too.  I don't want to hard-code addresses if I can avoid it. :-)

Many thanks.
Regards,