Re: [manet] DLEP address semantics and in-the-wild examples

Rick Taylor <rick@tropicalstormsoftware.com> Fri, 12 November 2021 17:10 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 D5C863A0C58 for <manet@ietfa.amsl.com>; Fri, 12 Nov 2021 09:10:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 bkYvjh4QB39s for <manet@ietfa.amsl.com>; Fri, 12 Nov 2021 09:10:15 -0800 (PST)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69613A0C30 for <manet@ietf.org>; Fri, 12 Nov 2021 09:10:14 -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.0513.000; Fri, 12 Nov 2021 17:10:08 +0000
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>, "manet@ietf.org" <manet@ietf.org>
CC: "Taylor, Rick" <rick.taylor@airbus.com>
Thread-Topic: DLEP address semantics and in-the-wild examples
Thread-Index: AdfJsKqKpmCmleWIRFCbVSebPhxs9gONu19Q
Date: Fri, 12 Nov 2021 17:10:07 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F98020B1B9688@tss-server1.home.tropicalstormsoftware.com>
References: <56203b289b7940afb8ce11f6cc375e98@jhuapl.edu>
In-Reply-To: <56203b289b7940afb8ce11f6cc375e98@jhuapl.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2a02:1648:4000:120:98bc:432d:a458:5391]
Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F98020B1B9688tssserver1hom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/XB6OfbrwShZdyrYIFcj_z54SBRg>
Subject: Re: [manet] DLEP address semantics and in-the-wild examples
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, 12 Nov 2021 17:10:20 -0000

Hi Brian,

Your first assumption is correct.  The MAC address of the interface the router uses to maintain the DLEP session is the MAC address used as a Destination identifier by its peers.  DLEP does not (currently) define an 'out-of-band mode' where the DLEP session is maintained on a different MAC address from the data-plane.

One could define an out-of-band mode by a router using a Destination Up message with an alternate data-plane MAC address, but that is currently not defined anywhere.

Cheers,

Rick

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Sipos, Brian J.
Sent: 25 October 2021 16:05
To: manet@ietf.org
Cc: Taylor, Rick
Subject: [manet] DLEP address semantics and in-the-wild examples

All,
I am in the process of investigating and implementing a DLEP router component and trying to figure out which sets of data items are available for which contexts (peer session vs. destinations) and how they must/may be interpreted.
Specifically, it's not fully clear to me what the IPvX and MAC Address data items [1] are allowed or required to represent for a peer (modem) or a destination (other router). My assumption is that the IPvX are addresses on which the router sends/receives traffic for forwarding on past the DLEP-informed link and the IPvX Attached Subnets are those to-be-forwarded nets, but the MAC Address is really an opaque identifier for the far-side destination and may or may not be an address actually associated with or seen by any of the routers.

In the Link Identifier extension [2] it's more explicitly stated that the MAC Address is supposed to be an address on the far-side router, but I don't see that same kind of language in the original DLEP document [1]. And since there is no signaling of the router MAC Address within the Session Initialization, I assume that it is implied that the MAC Address of the peer (router) used to establish the TCP connection is used for this purpose. For multi-interface routers there may be no relation between the MAC Address and it's routed-traffic IPvX addresses (if the router is talking DLEP on a different interface than the routed traffic), but if the MAC Address is supposed to be just an opaque identifier then this doesn't really matter.

I've been able to dig into the OONF [3] implementation of DLEP to see how it works, but this is just one implementation and not an authority of the correct or possible semantics.

Thanks for any clarification,
Brian S.

[1] https://www.rfc-editor.org/rfc/rfc8175.html
[2] https://www.rfc-editor.org/rfc/rfc8703.html
[3] https://github.com/OLSR/OONF