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

"Sipos, Brian J." <Brian.Sipos@jhuapl.edu> Mon, 25 October 2021 15:05 UTC

Return-Path: <Brian.Sipos@jhuapl.edu>
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 40EEE3A0B53 for <manet@ietfa.amsl.com>; Mon, 25 Oct 2021 08:05:04 -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, HTML_MESSAGE=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=jhuapl.edu
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 zVjqxLrM4mN7 for <manet@ietfa.amsl.com>; Mon, 25 Oct 2021 08:04:59 -0700 (PDT)
Received: from aplegw02.jhuapl.edu (aplegw02.jhuapl.edu [128.244.251.169]) (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 E18913A0B88 for <manet@ietf.org>; Mon, 25 Oct 2021 08:04:58 -0700 (PDT)
Received: from pps.filterd (aplegw02.jhuapl.edu [127.0.0.1]) by aplegw02.jhuapl.edu (8.16.0.43/8.16.0.43) with SMTP id 19PF2q1R043524; Mon, 25 Oct 2021 11:04:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=JHUAPLDec2018; bh=bzsAWldig9DPu5Gnx9DQn/NDO8gbfQAD5im21cjgqws=; b=Z8ZT5RuI5PYuAPepycd14bQ0cOuCt8Ch4FR6FkiX1u/fgAy/R/H/dsH8GhhONJxVj6+l Ewi/reuuUDX58YZpq6iNNhd5lINSWPs/XaMs5XhDlITy/hF0FkEkfgAHwGd7HfRa73+A 836jtk6cvHdjjTvnjQIIcv+wPsB3z40kTWzEQ5Vcx+P7W/tewZLQM4uSeVecDbXoJY/b 3Qku4SgHJG52X6c3NU7iHOPeg5//8W+7F9IhtJo5DFS48zgr5+RA36iyprFMZcGXzVE0 FoUCIbDBl0WSm7OELld6Q1fwwXDjF3TvRyMJhEWnB6XVEX/1BEfpiysrSXwqTvXH8HW8 Aw==
Received: from aplex02.dom1.jhuapl.edu (aplex02.dom1.jhuapl.edu [128.244.198.6]) by aplegw02.jhuapl.edu with ESMTP id 3bvem19ay0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Oct 2021 11:04:51 -0400
X-CrossPremisesHeadersFilteredBySendConnector: aplex02.dom1.jhuapl.edu
Received: from APLEX25.dom1.jhuapl.edu (10.114.162.10) by aplex02.dom1.jhuapl.edu (128.244.198.6) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Mon, 25 Oct 2021 11:04:51 -0400
Received: from APLEX21.dom1.jhuapl.edu (10.114.162.6) by APLEX25.dom1.jhuapl.edu (10.114.162.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.13; Mon, 25 Oct 2021 11:04:50 -0400
Received: from APLEX21.dom1.jhuapl.edu ([fe80::61c3:f0b7:2fc7:8018]) by APLEX21.dom1.jhuapl.edu ([fe80::61c3:f0b7:2fc7:8018%5]) with mapi id 15.02.0922.013; Mon, 25 Oct 2021 11:04:50 -0400
From: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>
To: "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: AdfJsKqKpmCmleWIRFCbVSebPhxs9g==
Date: Mon, 25 Oct 2021 15:04:50 +0000
Message-ID: <56203b289b7940afb8ce11f6cc375e98@jhuapl.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.162.27]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_005C_01D7C990.20B55FB0"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: aplex02.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-25_05:2021-10-25, 2021-10-25 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/Nm8Ce3y98lD6YQEjVcu_G1UVjn4>
X-Mailman-Approved-At: Mon, 25 Oct 2021 09:16:51 -0700
Subject: [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: Mon, 25 Oct 2021 15:05:04 -0000

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