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

Klaus Hartke <hartke@projectcool.de> Wed, 01 April 2020 10:56 UTC

Return-Path: <hartke@projectcool.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EBF3A0867 for <core@ietfa.amsl.com>; Wed, 1 Apr 2020 03:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TxRAmVildKj for <core@ietfa.amsl.com>; Wed, 1 Apr 2020 03:56:25 -0700 (PDT)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D6F3A086A for <core@ietf.org>; Wed, 1 Apr 2020 03:56:25 -0700 (PDT)
Received: from mail-qk1-f178.google.com ([209.85.222.178]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1jJb2l-0003Z7-1l; Wed, 01 Apr 2020 12:56:23 +0200
Received: by mail-qk1-f178.google.com with SMTP id q188so26473637qke.8 for <core@ietf.org>; Wed, 01 Apr 2020 03:56:23 -0700 (PDT)
X-Gm-Message-State: ANhLgQ3cODmKcJ/yuYUOVYBojnejCUYspMSJBe3Pos7pBgwnfWlEmJqN eXH3Law2dqPTV80rZs2e5fHLd2nhLzGgtI9XrSE=
X-Google-Smtp-Source: ADFU+vt8fvrpueaofqxRocp454rokNziDzf1FvcYPVqn25F5eArCXM+wuRFrkBLsmt/q0qsk8KnNpwrUI7KesDfE7Og=
X-Received: by 2002:a05:620a:2f7:: with SMTP id a23mr8584476qko.303.1585738581944; Wed, 01 Apr 2020 03:56:21 -0700 (PDT)
MIME-Version: 1.0
References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <AM5P190MB027536259A44102F7AB9E058FDC80@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <CAAzbHvbeEyws+wVchovoVTK=WutWoHCNcfv8LrpxmshLxJ_w+Q@mail.gmail.com> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <AM5P190MB0275218BA7C801E50C8353F0FDC90@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <CAObGJnOscTtyeQ+qvD0N0w_TD2JfV8h9+=zf=bz-jrr7LWhD2Q@mail.gmail.com>
In-Reply-To: <CAObGJnOscTtyeQ+qvD0N0w_TD2JfV8h9+=zf=bz-jrr7LWhD2Q@mail.gmail.com>
From: Klaus Hartke <hartke@projectcool.de>
Date: Wed, 1 Apr 2020 12:55:45 +0200
X-Gmail-Original-Message-ID: <CAAzbHvaJy9WfMOzzKhczreuZBcbA5TDQ5ThtGMT7eVj2Jf83gQ@mail.gmail.com>
Message-ID: <CAAzbHvaJy9WfMOzzKhczreuZBcbA5TDQ5ThtGMT7eVj2Jf83gQ@mail.gmail.com>
To: Thomas Fossati <tho.ietf@gmail.com>
Cc: Esko Dijk <esko.dijk@iotconsultancy.nl>, Jim Schaad <ietf@augustcellars.com>, "core@ietf.org" <core@ietf.org>
Content-Type: multipart/mixed; boundary="000000000000e24f1005a2388832"
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1585738585; 10dc3dd0;
X-HE-SMSGID: 1jJb2l-0003Z7-1l
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/7P8wrsahiuCriozrYc_fVyS6mzg>
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 10:56:28 -0000

Thomas Fossati wrote:
> I don't have an opinion yet, but I'd need some clarification about the
> above before feeling comfortable with the direction...

I guess there is some room for debate on what a CoAP endpoint with a
multicast IP address precisely means... RFC 7252 defines 224.0.1.187
as the "All CoAP Nodes" address. So I see at least two possible
interpretations for the endpoint 224.0.1.187:9999:

1. All CoAP nodes that are listening on port 9999 on their unicast IP address.

2. All CoAP nodes that are "subscribed" to mailing list 9999.

Both seem to have advantages and disadvantages. Maybe there are even
more interpretations?

> I have the same trouble as you understanding the port mapping part.
> Where is that supposed to happen (kernel, CoAP stack, application)?
> And why is it needed?

I always imagined multicast CoAP to work roughly like this:

+---------------+                +-----------------+
|               |    request    _|_                |
|               |        .---> /   \   224.0.1.187 |
|              _|_      /      \___/ --.   :9999   |
| 192.168.0.1 /   \ ---´         |      \          |
|   :54321    \___/ <---.       _|_     /  rewrite |
|               |        \     /   \ <-´           |
|               |         `--- \___/ 192.168.0.100 |
|               |    response    |         :5683   |
+---------------+                +-----------------+
      Client                           Server

So, a server is listening for request messages on both a unicast IP
address/port and a multicast IP address/port. If a request message
arrives on the multicast IP address/port, it "rewrites" the UDP
destination to its unicast IP address/port and then processes the
message as if it had received it on its unicast IP address/port.

The "rewrite" is at least needed for the IP address, because the
server cannot send its response from the multicast IP address.

Klaus