Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

[Esko Dijk <[e-mail]>]

Hi Achim, Jim,

CoAP did not define (for multicast) that the *matching* done on the client is based on the source endpoint of the response, you're right about this.
However CoAP does define that a Server responds from the same endpoint that received the request, I believe. See below text quotes and analysis.

In Section 2.1:
  The CoAP messaging model is based on the exchange of messages over UDP between endpoints.
[seems to hint at 2 endpoints. Although more would be possible.]

And Section 1.2:

  Endpoint
      An entity participating in the CoAP protocol.  Colloquially, an
      endpoint lives on a "Node", although "Host" would be more
      consistent with Internet standards usage, and is further
      identified by transport-layer multiplexing information that can
      include a UDP port number and a security association
      (Section 4.1).
[this defers to Section 4.1 and seems to hint that different UDP port numbers define different endpoints.]

   Server
      The destination endpoint of a request; the originating endpoint of
      a response.
[this seems intended as one endpoint on which the server lives; see below]

And in 4.1.  Messages and Endpoints:

   A CoAP endpoint is the source or destination of a CoAP message.  The
   specific definition of an endpoint depends on the transport being
   used for CoAP.  For the transports defined in this specification, the
   endpoint is identified depending on the security mode used (see
   Section 9): With no security, the endpoint is solely identified by an
   IP address and a UDP port number.  With other security modes, the
   endpoint is identified as defined by the security mode.
[this mentions UDP port number defines endpoints, in case of no-security mode i.e. multicast CoAP + UDP usage]

So what this tells me is that the server lives at a specific endpoint (identified by IP address and port) that receives a request, and will respond from that same endpoint. (Otherwise it would be a different server responding, living at a different endpoint!)
Or turning it around: if the server would be allowed to respond from another port number, it implies that there is one CoAP server residing on multiple endpoints.  And that seems to go against server as "destination endpoint of a request; the originating endpoint of a response" , or not?
I would interpret this as a server being on only one endpoint.  Because if not, then also for the unicast case  the server could be allowed to respond from a different endpoint because that server lives on multiple endpoints then.

Note there is slightly more information that adds to RFC 7252 in the draft section https://tools.ietf.org/html/draft-ietf-core-groupcomm-bis-00#section-2.3.1. But it does not explain the present issue, though, only details the matching at the client side.
Feel free to challenge my RFC 7252 interpretation, maybe I overlooked something.

Best regards
Esko


-----Original Message-----
From: core <[e-mail]> On Behalf Of Achim Kraus
Sent: Friday, March 27, 2020 19:00
To: Jim Schaad <[e-mail]>; [e-mail]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hi Jim,

thanks for the fast answer!

 > The unicast responder does not need to be on the default COAP port
number.

It's more the destination port of the request than the default CoAP port.

 > This would be especially true if you had two different server running
 > on the same piece of hardware. I find this to be very common for me in
 > testing because I am running 10 different CoAP servers on my laptop
 > and while they can share the multicast addresses, they need to end up
 > on different unicast ports.

OK, I see. Interesting. Using  different ports for multicast and unicast
makes it also easier to distinguish multicast from unicast.

(On the other side, it kills somehow the idea of a "service, bound to a
port" and it makes tracking the traffic with wireshark harder :-).
I will see, when I can spend some time into adjust the server-side
according this idea in your answer.)

best regards
Achim


Am 27.03.20 um 17:14 schrieb Jim Schaad:
>
>
> -----Original Message-----
> From: core <[e-mail]> On Behalf Of Achim Kraus
> Sent: Thursday, March 26, 2020 11:39 PM
> To: [e-mail]
> Subject: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page
> 67, top
>
> Hi list,
>
> RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top
>
> "When matching a response to a multicast request, only the token MUST match;
> the source endpoint of the response does not need to (and will
> not) be the same as the destination endpoint of the original request."
>
> (4.1. Messages and Endpoint, "With no security, the endpoint is solely
> identified by an IP address and a UDP port number")
>
> Though it is obvious, that the IP address part is changing (from multicast
> destination to a unicast source), I 'm not sure, why the port should be
> considered to change as well.
>
>
> example:
> 192.168.1.50:15683 -> 224.0.1.187:5683   (multicast request)
>
> 192.168.1.50:15683 <- 192.168.1.40:5683  (unicast response, I would expect)
>
> 192.168.1.50:15683 <- 192.168.1.40:7843  (unicast response, the spec.
> also allows)
>
> So,
>
> - was a change of the port (2. example response) considered when writting
> that definition?
> - if yes, what was the reason to do so?
>
> [JLS] My response would be that the answer is yes.  The unicast responder
> does not need to be on the default COAP port number.  This would be
> especially true if you had two different server running on the same piece of
> hardware.   I find this to be very common for me in testing because I am
> running 10 different CoAP servers on my laptop and while they can share the
> multicast addresses, they need to end up on different unicast ports.
>
> Jim Schaad
>
>
> best regards
> Achim Kraus
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>

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