Re: [manet] Clarification on DLEP RFC 8175

Rick Taylor <rick@tropicalstormsoftware.com> Tue, 08 January 2019 11:01 UTC

Return-Path: <rick@tropicalstormsoftware.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 9EF36131104 for <manet@ietfa.amsl.com>; Tue, 8 Jan 2019 03:01:11 -0800 (PST)
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_PASS=-0.001, URIBL_BLOCKED=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 CbJe7fA4EQ_r for <manet@ietfa.amsl.com>; Tue, 8 Jan 2019 03:01:08 -0800 (PST)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [IPv6:2a02:1648:4000:120::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65669131103 for <manet@ietf.org>; Tue, 8 Jan 2019 03:01:08 -0800 (PST)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0415.000; Tue, 8 Jan 2019 11:01:02 +0000
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: "ujenreznik@gmail.com" <ujenreznik@gmail.com>, "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] Clarification on DLEP RFC 8175
Thread-Index: AQHUprHSFmXR1NTOBUyJjjg2ZuOw2aWlNW2A
Date: Tue, 8 Jan 2019 11:01:01 +0000
Message-ID: <699e9b63c111d2106ae4050e2c2e39f57460b29d.camel@tropicalstormsoftware.com>
References: <CANs5VwfTkuvWFyQ7xe3yPAz4t4y+kdc8rWaW1DtMQQiSzmSwGw@mail.gmail.com>
In-Reply-To: <CANs5VwfTkuvWFyQ7xe3yPAz4t4y+kdc8rWaW1DtMQQiSzmSwGw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.1.5]
Content-Type: text/plain; charset="utf-8"
Content-ID: <294998674D6DCC42AE55D5E299607FB6@home.tropicalstormsoftware.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/SHv2FPmdwlO6m9SX1QkN5YtPHD0>
Subject: Re: [manet] Clarification on DLEP RFC 8175
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: Tue, 08 Jan 2019 11:01:12 -0000

Hi Eugene,

Comments inline...

On Mon, 2019-01-07 at 19:52 +0200, Eugene Reznik wrote:
> Hello,
> 
> I have a question about the DLEP RFC and specifically about the
> discovery process.
> In paragraph 12.3 Peer Discovery signal RFC says:
> " A Peer Discovery Signal MUST be encoded within a UDP packet. The
> destination MUST be set to the DLEP well-known address and port
> number. "
> 
> In paragraph 12.4 Peer Offer Signal RFC says:
> " A Peer Offer Signal MUST be encoded within a UDP packet. The IP
> source and destination fields in the packet MUST be set by swapping
> the values received in the Peer Discovery Signal. "
> 
> In paragraph 15..15 RFC says:
> "DLEP IPv4 Link-Local Multicast Address IANA has assigned the IPv4
> multicast address 224.0.0.117 in the registry found at ..."
> 
> As far as I understand, these rules essentially lead to the following
> situation: the modem MUST form a UDP packet where the source IP
> address is multicast 224.0.0.117.
> Can you please clarify if this is the intention of RFC or did I
> misunderstand it?

Yes I agree, the text is confusing and possibly wrong.  The situation
is made worse by the text at the end of paragraph 4 in section 7.1 "If
no Connection Point Data Items are included in the Peer Offer Signal,
the router MUST use the source address of the UDP packet containing the
Peer Offer Signal as the IP address, and the DLEP well-known port
number."

The intention of the authors (and what all my implementations do) is:

M> The modem binds a UDP socket to the DLEP well-known multicast
addresses/ports, and starts a recvfrom().

R> The router sends a Peer Discovery signal to the DLEP multicast
address, setting the UDP packet destination address to the multicast
address/port and the packet source address to an address on the DLEP
interface, using an unused (ephemeral) local port [Section 12.3].  It
then starts a recv() on the local address/ephemeral port.

M> The modem receives the Discovery signal from the router, and replies
with whatever information it wants by *unicasting* the Peer Offer
signal back to the router, using incoming packet's source address/port
as the destination, and setting the source address/port of the UDP
packet to one of the following:

 * If the Peer Offer signal includes one or more Connection Point Data
Items, then the source address/port is irrelevant.

 * If the Peer Offer signal does not include a Connection Point Data
Item then the source address MUST be the IP address with which the
modem is willing to accept TCP connections, but the port is irrelevant.

R> When the router receives the Peer Offer response, it follows the
rules defined by paragraph 4 of section 7.1.

In summary, I believe paragraph 2 of section 12.4 is incorrect.  Can
you raise an errata please (https://www.rfc-editor.org/errata.php), and
we can address it formally?

Thanks for pointing out the issue, and I hope this helps.

Cheers,

Rick