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

Thomas Fossati <tho.ietf@gmail.com> Wed, 01 April 2020 15:41 UTC

Return-Path: <tho.ietf@gmail.com>
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 DFD3E3A114B for <core@ietfa.amsl.com>; Wed, 1 Apr 2020 08:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 amybRzCTRCAm for <core@ietfa.amsl.com>; Wed, 1 Apr 2020 08:41:30 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 688553A114A for <core@ietf.org>; Wed, 1 Apr 2020 08:41:30 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id n10so144341iom.3 for <core@ietf.org>; Wed, 01 Apr 2020 08:41:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6s4deMO0qNju8QVxWm+ilbfg947Dhy4E30O5bXiMSeQ=; b=QLwImT0HihGlXols0f0yoye63oEppePuNOH7T2LOAz9GzFqc96cFR7zKIcG/9XGnIJ UbdND/9XghUPtUvxExIeQM2PP30Iv/MNJY1WrrD6joXrox92QRIu11iJ1zeI6Ttpuxb/ ECUdUOLMgU3GeTzQgUsHoc2EHz5aPoWebj7triHFdlO51ULcxtjZxXxHH/WLukgLQFrc pE2vEyyuRiADi7gzunAXHe0f5svFJxd+psTUTDKwup0hY2J2nWOVhENPyw2Jf3GUf+4r mjRbylP2xayfXrBA+9FB1fVhLuJvgbb2dg6aOftqxuEno/lR9WRLkd0LnWtNgbzbiy+6 t/qA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6s4deMO0qNju8QVxWm+ilbfg947Dhy4E30O5bXiMSeQ=; b=eonsoVujr6VTJtlBKrAtOwFV1l3xoXR1sQ8BZD/DGE4fQGBctiCc1FQXuaXLlyF3g+ BR8qIW6tKiheBqXYQtYJKDr0jFlpS1sSp/Yz4t6fNCic9GfsvTMCnuMihdh2s3AxOxjL IawAQ0GbZ1v4zzF3S1/RD3g5bCaswcU8osIlYxa1pV44mADDRYILhyBpCraQSduilzn2 NVbPUOLs5ezMH63inxzi06VHIau3IpeVeRKvUE2MuOAAvm/F4bbjYg7ohH83Gk9NHO5M M+kisZB5n6DCx6X4pxHNNLAGXiOW6hAsyksjG90BxtngDAsWApnPJtn8HpDOD4Q3Mo4N 20yQ==
X-Gm-Message-State: ANhLgQ39ixnnFPko+2t9YpFPF//6fJZzasiwxssJuwSxDwPdxulo4XGm 4dVBbcFlgTIZhBG/WxYFmWDGJA9i6nj2m2U/Aey1zkPb
X-Google-Smtp-Source: ADFU+vsL5/VODD2Q1OOYVClalHoVFHtacBTGA+f/ufkJRjUCCtHwXvH3kmA1VX+RjR/6CQY6gSj37sb4o8IQ+dC3GkY=
X-Received: by 2002:a6b:8fd7:: with SMTP id r206mr21099898iod.109.1585755689542; Wed, 01 Apr 2020 08:41:29 -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> <CAAzbHvaJy9WfMOzzKhczreuZBcbA5TDQ5ThtGMT7eVj2Jf83gQ@mail.gmail.com>
In-Reply-To: <CAAzbHvaJy9WfMOzzKhczreuZBcbA5TDQ5ThtGMT7eVj2Jf83gQ@mail.gmail.com>
From: Thomas Fossati <tho.ietf@gmail.com>
Date: Wed, 1 Apr 2020 16:41:18 +0100
Message-ID: <CAObGJnOcP_FxNuORqAvpBE-P+nRdPjxcXVdb-VTN5in5obanmw@mail.gmail.com>
To: Klaus Hartke <hartke@projectcool.de>
Cc: Esko Dijk <esko.dijk@iotconsultancy.nl>, Jim Schaad <ietf@augustcellars.com>, "core@ietf.org" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/lsPSTx9KLpY46REQ0-ZtCAVZQ90>
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 15:41:32 -0000

Hey Klaus,

On Wed, Apr 1, 2020 at 11:56 AM Klaus Hartke <hartke@projectcool.de> wrote:
> 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.

This interpretation doesn't look right to me.

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

This is how I interpret it.

> > 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.

Not sure why you would also want to rewrite the transport endpoint?

cheers, thanks!