Re: [manet] Proposed text for Errata 6472 (and friends)

Henning Rogge <hrogge@gmail.com> Fri, 19 November 2021 09:48 UTC

Return-Path: <hrogge@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5413A0CEF for <manet@ietfa.amsl.com>; Fri, 19 Nov 2021 01:48:58 -0800 (PST)
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 zK-ogKrFT9Xc for <manet@ietfa.amsl.com>; Fri, 19 Nov 2021 01:48:54 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 AD2FC3A0CEB for <manet@ietf.org>; Fri, 19 Nov 2021 01:48:53 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id y26so40682305lfa.11 for <manet@ietf.org>; Fri, 19 Nov 2021 01:48:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FjM/I2lyXoUWfzLZLIFsRAHWCKrVnUVVZ5NX3mTqSPc=; b=g1yJA3i/F3S+/KuJuJvJp7E3T+4zslmVU3Xf+OKp6EvoM8lIW+T6Nkx1nQJgh76OmK ZPpJStVYWNbfR8r/pVOfljtlucg4NJ5YLEg0WQHSrHOugyEAnK8HFVgQEJLlRxLnlRY9 nMAFB5W+a3lysNAbnBrrs8LmFpe3swT1AWAzKYBv/XHu57Srk8oRRAoJAbOcnpmny3ve CDbA497mFAv0NCN9mnpNoPlRIgERVipH69AnZ3oDEyFgaSUt8zvRx5nz2Iq35RQO3YIN 1UMiSN6SgiVpsXOeaxNnVvRWl+po+qXf/gGW1K0fESrpws8L+61Z6JFjrn2r6XxN7OxS qoeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FjM/I2lyXoUWfzLZLIFsRAHWCKrVnUVVZ5NX3mTqSPc=; b=Wmr3+hhTODmD+6JZCYT/6TIamla7UPNUxg6WG9ompqLkzUt58P7plmZjmgWqxbKp9p /HJP9tKyyswe6Vjol/wQLxYERJ1ZcBcWYWJryukZamIc1plnoFzAnXIV0su56xGr8juv y7a55sSHFxfDbXzCunHJMSXWXK7X9ctzKY5OGkjsq/1PkegR5Kl0fXI1XWQ3U3xHRW+A eyCnDBXwXQTluNPRrJT8EPAbX9vWDTLKy1Uoi2J164J421DYh3O8PIsMxvEpMoNGoka0 p5KoEEp/m7thSC3ztfrWKcxEBzdImfykz9Tv+IunGymTq86DDuLOl8/vTysub/pZj685 vsPw==
X-Gm-Message-State: AOAM533vVX14RvrZ1+697uGg4sazJaKW1ClfiU00TM3m7mfPjSU0Uq05 aNJ3Vs49ghV8mbcBOCZkpEAdkgFnWx9N2uNkwSo=
X-Google-Smtp-Source: ABdhPJwN1h2MK6Iy4ENNwpRTvf/NcBHvvUpuarhGyHXo93tyFR3CD1SEttU/2eTewYocyuWLE3AsU7eeobE+FXduzbw=
X-Received: by 2002:ac2:4c42:: with SMTP id o2mr31477886lfk.504.1637315326792; Fri, 19 Nov 2021 01:48:46 -0800 (PST)
MIME-Version: 1.0
References: <38A5475DE83986499AEACD2CFAFC3F98020B1B9639@tss-server1.home.tropicalstormsoftware.com> <7a3901baf5da4bbeb23adee80a5be596@jhuapl.edu> <CAGnRvurGXxcmbX_s5btwvvTvXnta50Zj=dzOBnM1TkuEW4RT8A@mail.gmail.com> <38A5475DE83986499AEACD2CFAFC3F98020B1BB18D@tss-server1.home.tropicalstormsoftware.com>
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98020B1BB18D@tss-server1.home.tropicalstormsoftware.com>
From: Henning Rogge <hrogge@gmail.com>
Date: Fri, 19 Nov 2021 10:47:42 +0100
Message-ID: <CAGnRvuoVrjKNh__Dp1L4pg+A6vKC9j0qzkoF4hno1tgGDX9oRA@mail.gmail.com>
To: Rick Taylor <rick@tropicalstormsoftware.com>
Cc: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>, "manet@ietf.org" <manet@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/sN4LBxgFcsRB9nG3R-SSGpwz_Rc>
Subject: Re: [manet] Proposed text for Errata 6472 (and friends)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 09:48:58 -0000

Hi,

I think at least some of the issues arise because modern IP radios
often have weird, small or sometimes incomplete IP stack
implementations... so you sometimes have to choose your source and
destination MAC for your outgoing packets.

I remember at least one radio whose IP stack crashed as soon as it
tried to parse a fragmented IP packet... and its HTTP server could not
handle requests distributed over more than one IP packet either.

Henning

On Fri, Nov 19, 2021 at 10:39 AM Rick Taylor
<rick@tropicalstormsoftware.com> wrote:
>
> Hi Both,
>
> IPv4/6 Connection Point data items contain a port number, so there is no confusion about which port to use to establish the TCP session when the Data Item is included in the response.  The Source IP/port in the response is irrelevant - it just needs to be 'valid' (i.e. not multicast, etc).  The source port can be ephemeral, as nothing is listening for anything further on that port.
>
> When Connection Point data items are missing, set the Source IP/Port of the Peer Offer response packet to the TCP IP/port combo that is listening for the TCP session connect().  In most cases, that will be the same IP address and port (854) as the Discovery UDP is using, so there is little to do programmatically, it's only difficult when the ports are different.
>
> In either case, always set the destination IP/port to the Source combo of the original Discovery signal.
>
> When writing this using the BSD sockets API, a lot of this ephemeral port detail is skipped thanks to the API.  As a modem:
>
> 1. Create a S1 = socket(UDP)
> 2. bind(S1) to DLEP interface, port 854.
> 3. Join the multicast group
> 4. recvfrom(S1, Peer Discovery)
> 5a. If we use Connection Point Data Items, or use the same address and port 854 for the TCP session:   sendto(S1, Peer offer) to source sockaddr of the received packet.
> 5b. Else: create a new S2 = socket(UDP) and bind(S2) to DLEP interface, UDP port = custom TCP port, then sendto(S2, Peer offer) to source sockaddr of the received packet.
>
> Does that help?
>
> Cheers,
>
> Rick
>
> > -----Original Message-----
> > From: Henning Rogge [mailto:hrogge@gmail.com]
> > Sent: 19 November 2021 08:44
> > To: Sipos, Brian J.
> > Cc: Rick Taylor; manet@ietf.org
> > Subject: Re: [manet] Proposed text for Errata 6472 (and friends)
> >
> > You cannot do the receiver for the UDP discovery packets on an
> > ephemeral port anyways... wouldn't it be the usual thing just use the
> > same socket for sending the unicast reply?
> >
> > Henning Rogge
> >
> > On Tue, Nov 16, 2021 at 11:26 PM Sipos, Brian J. <Brian.Sipos@jhuapl.edu>
> > wrote:
> > >
> > > Rick,
> > > For the first condition (connection point is present) there is still a lack of
> > > preference for UDP port number, which leaves things open. Can the source
> > UDP
> > > port in that case be required (even a SHOULD would help) to be the same
> > port
> > > number listened-for by the modem (i.e. the destination the port number of
> > the
> > > Peer Discovery Signal)?
> > >
> > > In a typical case, I expect the modem would be listening on standard UDP
> > port
> > > 854 so the Peer Offer would have a source port of 854. This makes things
> > > easier on traffic monitors so that it's not a UDP datagram from
> > > ephemeral-to-ephemeral port. It could also simplify implementation
> > because the
> > > listening bound socket would also be usable for sending the response.
> > >
> > > Thanks,
> > > Brian S.
> > >
> > > -----Original Message-----
> > > From: manet <manet-bounces@ietf.org> On Behalf Of Rick Taylor
> > > Sent: Friday, November 12, 2021 11:36 AM
> > > To: manet@ietf.org
> > > Subject: [EXT] [manet] Proposed text for Errata 6472 (and friends)
> > >
> > > APL external email warning: Verify sender manet-bounces@ietf.org before
> > > clicking links or attachments
> > >
> > > Hi All,
> > >
> > > Here is my proposed text for the raised Errata.  Please review and
> > comment, as
> > > there are particular combinations of if/MUST/else that can be confusing.
> > >
> > > ------
> > > Section 12.4, para 2.  Replace with:
> > >
> > > A Peer Offer Signal MUST be encoded within a UDP packet. The destination
> > IP
> > > address and UDP port of the packet MUST be the source IP address and
> > UDP port
> > > of the received Peer Discovery Signal packet.  If the modem includes IPv4 or
> > > IPv6 Connection Point Data Items in the Peer Offer Signal then the source IP
> > > address and UDP port of the packet may be any valid local UDP
> > address/port
> > > combination.  If the Peer Offer Signal does not include IPv4 or IPv6
> > > Connection Point Data Items, then the source IP address and UDP port of
> > the
> > > packet MUST be set to the unicast IP address and TCP port the router MUST
> > use
> > > when connecting the DLEP TCP session, as defined in Section 7.1.  The Peer
> > > Offer Signal completes the discovery process.
> > > -----
> > >
> > > Cheers,
> > >
> > > Rick
> > >
> > > _______________________________________________
> > > manet mailing list
> > > manet@ietf.org
> > > https://www.ietf.org/mailman/listinfo/manet
> > > _______________________________________________
> > > manet mailing list
> > > manet@ietf.org
> > > https://www.ietf.org/mailman/listinfo/manet