IETF Logo Mail Archive

Re: [core] Using CoAP for P2P

Achim Kraus <achimkraus@gmx.net> Mon, 06 April 2020 13:29 UTC

Return-Path: <achimkraus@gmx.net>
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 CCE853A1AEF for <core@ietfa.amsl.com>; Mon, 6 Apr 2020 06:29:16 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 AB7W_O0JGYz9 for <core@ietfa.amsl.com>; Mon, 6 Apr 2020 06:29:04 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FEC3A0408 for <core@ietf.org>; Mon, 6 Apr 2020 06:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586179443; bh=ty5zdqNF6QPaZ25vCD36CvlEdTmx/IRfL53jb5a/Kas=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=ENgdS+OMBs23QJ/f83v4SQKc5qUCg2y5pCnZBshCTkeoiZEJltxJsF5gyrDQc22yK +0qTKnG/s7V3v03tnREGhOJvJ0f0N4rAeXOS4pLMEFmMbyTMzbI2rcGnJHRBhMyWQJ btpdHx3gVtx2hkDWrN/LHLhirBpFIYbEs8GgNzuU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([178.2.223.124]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1McpNy-1ilq403vqU-00ZyRZ for <core@ietf.org>; Mon, 06 Apr 2020 15:24:03 +0200
To: core@ietf.org
References: <CAEW_hyzh3FAvHi1eTkbyGn99o4nFgcH1xP90FdQ6N9sHsAJVYQ@mail.gmail.com> <A8E6E9AA-2E34-439E-8761-53385086CDB9@arm.com> <CAEW_hyy+0fViN8dMWiCi_QHjeD5J4DUAnoRUg5MAKS6fQ3DzcQ@mail.gmail.com> <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> <CAEW_hyzbtq6VbQMq5PhfAQjf6LLz-7t_9He-C_kaU5jztsf20A@mail.gmail.com> <CF1E6A23-243F-47A3-9DFB-BB244E96302B@ericsson.com> <CAEW_hyzsq8T9uXQYUacZ5VzWf7JsJ1xAzKEMaA-XemOWW06fBQ@mail.gmail.com> <F11ABE2A-89A9-4512-8708-B692B0AABB65@tzi.org> <8012E8F3-F21D-455E-B888-24C996D9C509@ericsson.com> <99FAF8E8-D93B-4AAC-919D-BEC9F614ED28@tzi.org> <CAEW_hywLqNcU4DD5tbXLqPO4WGH9g=mDWqH051dmXpYs53TFDw@mail.gmail.com>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <e452414c-0266-be43-26ae-50f30a4ed6db@gmx.net>
Date: Mon, 06 Apr 2020 15:23:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CAEW_hywLqNcU4DD5tbXLqPO4WGH9g=mDWqH051dmXpYs53TFDw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:k5JiM23URU19OqeZeCKghO7fMJjan+tvzRk4yl+tQrkW1R/NAO3 gBej7cpyemHgMlrS02vR+bFdFkuWa5HlMTlFbaua+jSD96D95Un5Q8rsc+Ml3MmEEWTiRmO Kkhz97q6hUo5gq75Ly7lZAcNVcY6/WBExqdXljTDXLizEdx929ELatoDB4sVCgvXCDhISx0 mCF01xUN2DpjbDZ8ZYIGw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:rH7672brutg=:kPhroG57G/infB5/1XC1ab SUDtmllnKuwrLOnIGyY3jTexOhHHJMSnIi7FWRJbbh6HfRGgn8lBAVnBeoAZgQYFnu5tTGAb+ h/zbX/Bepz3FRrdcm/2qaSCp2tUNEnwNI5+fA56JCflk8nKDH7ERKGvn8GGBqNu0pjTEOOln2 zij09fszTF1cjH5GT0VrJIeLLTCiAgXAxGq9plaoBLLeB1i+M7izFPaiApFPM5O9Gj/gEqJxz JAsRds8nOdxksH5sJdK218w2JjA2M5dQDiof/M+BvTLeDeYcdMC8y6frxVUbEY0hX3GoPd6Ff 42kTV4m/bmARO9HrBecQp6njVUKdQXiuHscihbffFua3kuKnpIuVToxsbgniqom9mrL9gqwsu VIMlv7ouv6hgQfcYHFJ4aNoUnIkeOmhUJkLr3eqPA0ai2fgxHJu/MiS0W36TBia1IiWzxWS4n +Rt2WG+pI9PGUHQZgnSznpZiiWZIXbYVmnXAjTiF9jAXZN0g/lZI++LDc9C0IqTEvf4sSTRsp RFF1TuUckrFJ277Du6wDGr7/jJVnaA6U+s3m9JPuaxslVhsLOqdbsmaR31yIIi7KDR9hYdIIQ wqNiFuzPwGzmZ7+l5EPKjFyfw+ASXGz+eZ04+hUA6vSVEY08HfbXZptAXHQxQh//G5GeqpABf ESD5QrETFVyBzAW29gnoZ7Tx+rIzW/bz94r2CaD+x0atsl96iWSGDCPAR6kTRjJ0FaWEJcCkp kHQQB6eRCJ6vsC5LIglGg6t+BVaTEVAvLTtImPo9J0EmtXgq9O8tnPHpld5RQVoIOLTa1/bDt K0gPQrPKwgnyObRESIo2GE68Nb8g2OMp7A22D26j5RWMCBhtOoQrLgj2yjpirNkukGYwR2Q2n K4jQWkH0j0ZApXZVUf964MtnmsWMLpw4XV3JIfwkT2IOdiDTGrXLGc9J+KWBm4eocM9MV8l22 6afwPKTOv43IOj+JmBN7/2LvxC8OsF2iuFqL8nAVTJjfRlt20nidPSabis+ZUdRL3mFe5da44 X7GY5LfwemYVvqRAfcK9yyqa5Qh+CcaAfyH0dMd6UhYslxGcsJ9o8uWkna8az3MUhrYUrZsZ1 hSLGMygRhFZ1OgNKxO2GhN+UfILFEAowpDTywQzXjTi3aKElYbto+7b1sBgQImlO7ba/72SDE 5Jk2ZnxheZYZs7hFf4K8nVh2WxffrSpWlFisRVKiN4kVm31qPFhNMMAhFUPko+UIHnop9ls4B jrC1h0blW1XLOhDOO
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/mCHzht0PDVonX-3VHTXpCScxvTI>
Subject: Re: [core] Using CoAP for P2P
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: Mon, 06 Apr 2020 13:29:21 -0000

Hi Abhijan,

in my experience it's not about IPv4 or IPv6 (and the feature assumed to
be included with both technologies).

It's about the nature of the network you use for your peers to
communicate. CoAP over UDP (also over DTLS/UDP) works without the need
of additional parts, if your peers can exchange messages using UDP.

So, is that network your peers are using fully under your control? As a
home-network maybe considered. So, you know, if your peers have static
or mainly static addresses. And there is nothing on the path between
your peers, which may block or modify your traffic? Then you have a very
good chance, that you don't need something additionally.

But, if your peers can't reach each other without additional parts, e.g.
because both in "their home network" and so communicate over a path,
which uses a "public internet link", then you need more.

Therefore, please try to describe first the network(s) and the
communication paths you plan to use for your peers.

best regards
Achim

Am 06.04.20 um 14:31 schrieb Abhijan Bhattacharyya:
> Hi Carsten,
> Considering the practical deployment possibilities, I think we are quite
> far from expecting a clean IPv6 path. My home broadband service provider
> still serves IPv4 only. :)
> Apart from that there may always be some firewall in place considering
> enterprise use cases and we would need to punch a hole.
> Thanks.
>
> On Mon, Apr 6, 2020 at 5:43 PM Carsten Bormann <cabo@tzi.org
> <mailto:cabo@tzi.org>> wrote:
>
>
>     On 2020-04-06, at 13:52, Christer Holmberg
>     <christer.holmberg@ericsson.com
>     <mailto:christer.holmberg@ericsson.com>> wrote:
>      >
>      > I am not going to get involved in a discussion about that,
>     because it is not CORE specific, but IPv6 is *NOT* going to remove
>     the need for NATs :)
>
>     Of course not, IPv6 is not removing IPv4… :-)
>
>     (That’s why I talked about a “clean” environment.)
>
>     Grüße, Carsten
>
>
>
> --
> Regards,
> Abhijan Bhattacharyya,
> /Technologist by profession [IoT| Internet Protocols| 5G]/
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

v2.23.0 | Report a Bug | By Email