Re: [core] RFC 7252 - 8.2 - Multicast

-----Original Message-----
From: core <core-bounces@ietf.org> On Behalf Of Achim Kraus
Sent: Thursday, March 26, 2020 11:39 PM
To: core@ietf.org
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
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

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