Re: [core] Using CoAP for P2P

Hi Achim,
I think we can put it this way:
When we consider a purely Client/Server mode, there is this inherent
assumption that usually the server will have the implicit responsibility to
make itself available through a known accessible path. This does not hold
as a general consideration when we want to do a P2P that should not depend
only on a given assumption about the path to reach the peers.

The peers may both be publicly addressable; one or both may be behind NAT/
Firewall; they may be in a home network where filtering rules are relaxed;
they may be in an enterprise network with stricter rules (at times you may
need the local infra admin to intervene to open specific ports -- let's
keep that out of consideration here). So, any possible standardization
effort should propose a mechanism that will allow the peers to access each
other agnostic of the intermediate topology and the back haul.

Thanks.

On Mon, Apr 6, 2020 at 7:07 PM Achim Kraus <achimkraus@gmx.net> wrote:

> 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
> >
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

-- 
Regards,
Abhijan Bhattacharyya,
*Technologist by profession [IoT| Internet Protocols| 5G]*