Re: [dtn] Fwd: New Version Notification for draft-ek-dtn-ethernet-00.txt

scott@solarnetone.org Sun, 16 July 2023 04:53 UTC

Return-Path: <scott@solarnetone.org>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA99C15109A for <dtn@ietfa.amsl.com>; Sat, 15 Jul 2023 21:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuGZDtWH4TXc for <dtn@ietfa.amsl.com>; Sat, 15 Jul 2023 21:53:41 -0700 (PDT)
Received: from www.solarnetone.org (solarnetone.org [IPv6:2602:fdf2:bee:feed::a1a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA40C151078 for <dtn@ietf.org>; Sat, 15 Jul 2023 21:53:41 -0700 (PDT)
Received: from scott (helo=localhost) by www.solarnetone.org with local-esmtp (Exim 4.96) (envelope-from <scott@solarnetone.org>) id 1qKtlK-0003h6-2G; Sun, 16 Jul 2023 00:53:38 -0400
Date: Sun, 16 Jul 2023 00:53:38 -0400
From: scott@solarnetone.org
To: Erik Kline <ek.ietf@gmail.com>
cc: dtn@ietf.org
In-Reply-To: <CAMGpriUpeggS7AmPsKxVC+6EQTZCKVGzX=EDBR+KoRjh_erfPg@mail.gmail.com>
Message-ID: <c913d7b5-b2e3-c1ed-5d89-2a9262d1e240@solarnetone.org>
References: <168900943162.4409.3081737227445844385@ietfa.amsl.com> <CAHYe194VUm9XGE_kGN7Q4UtrUvQ7Xmc7SoZ+gOUYPch_mFeHjA@mail.gmail.com> <CAMGpriUADNZNXNpb6tSq7XXR+dwb+kWQD_oPMfgwp1OBEMA4WA@mail.gmail.com> <ce799029-38e7-e7c0-733f-d82a2a51ec9f@solarnetone.org> <CAMGpriUpeggS7AmPsKxVC+6EQTZCKVGzX=EDBR+KoRjh_erfPg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="-2112414640-1397574012-1689483218=:19070"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/jySk7JOQcs78p_8VNXUoCkHqLuM>
Subject: Re: [dtn] Fwd: New Version Notification for draft-ek-dtn-ethernet-00.txt
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Jul 2023 04:53:45 -0000

Hi Erik,

On Sat, 15 Jul 2023, Erik Kline wrote:

> Scott,
>
> Thanks for the info.  I went looking through ion-open-source-4.1.2 and
> I can see where a tap interface is set up, but I cannot yet see where
> direct encap as an Ethernet payload is performed (I do see where
> IPv4/IPv6 packets are inspected, coming off the tap interface).  I'll
> keep looking, but if someone has a ready pointer that'd be great.

So the kernel interface defines both tun and tap devices.  IIRC, tap sends 
raw ethernet frames over an interface, while tun sends IP packets. 
Generally, one or more IP addresses are assigned to the tun/tap interface 
to make them useful.

Still, I am not sure, after further review, that bptap does all of what 
you are describing as the goal.  Directly to your question, I think those 
functions which perform that work are included from the kernel source with 
the linux/if.h and linux/if_tap.h includes.  All the bptap code does is 
read/write to a virtual network interface, in that regard, and the kernel 
handles the rest.  That virtual interface could be bonded to a physical 
interface, but we still need a way to tell ION what mac address to send 
to, I think.

It is in the contact graph where we define nodes associated with IP 
addresses or something else.  Theoretically, we could make a CLA that has 
mac addresses defined for contact, as opposed to ip addresses or other 
physical interfaces (tty, for example) and have bundles directly 
encapuslated over ethernet frames in this manner.  Is that what you are 
suggesting?

>
> Was an EtherType formally registered for BP-over-Ethernet?  I saw in
> the DTNME codebase [DTNME] where they appear to have an encap scheme,
> using an EtherType of 0xd710, but I can't see that value registered in
> any of the convenient EtherType lists [IANA802, IEEE802].
>

Seems a good idea if the concept is to be standardized, to have that entry 
in the approrpiate registry(ies).  If there is operational precedent for a 
given value, all the better?

Scott

> Thanks,
> -Erik
>
> DTNME: https://github.com/nasa/DTNME/blob/master/servlib/conv_layers/EthConvergenceLayer.h
> IANA802: https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml
> IEEE802: https://standards-oui.ieee.org/ethertype/eth.txt
>
> On Fri, Jul 14, 2023 at 8:36 PM <scott@solarnetone.org> wrote:
>>
>> Hi Erik,
>>
>> I believe something like this exists, which uses the linux kernel tun/tap
>> interface to write frames or packets, per configuration.  It is called
>> bptap, and is distributed with ION.
>>
>> ScottJ
>>
>> On Fri, 14 Jul 2023, Erik Kline wrote:
>>
>>> All,
>>> I had been thinking about passing Bundles directly between/among Ethernet
>>> peers (some RF links with MACs that are Ethernet like, and also some cloud
>>> networking scenarios).  I took a stab at writing something down to help
>>> formalize this.
>>>
>>> I have already received some unicast feedback about wanting support for
>>> non-BP-native fragmentation and other options.  I think using the first byte
>>> to differentiate  among {BPv6, BPv7, variant of RFC 8200 S4.5 fragment
>>> header, something indicating RFC 9174 XFER_SEGMENTs, ...} should be quite
>>> easy to write.  But I figured I'd see what y'all think.
>>>
>>> Hope to see folks in SF,
>>> -Erik
>>>
>>> ---------- Forwarded message ---------
>>> From: <internet-drafts@ietf.org>
>>> Date: Mon, Jul 10, 2023 at 10:17 AM
>>> Subject: New Version Notification for draft-ek-dtn-ethernet-00.txt
>>>
>>> A new version of I-D, draft-ek-dtn-ethernet-00.txt
>>> has been successfully submitted by Erik Kline and posted to the
>>> IETF repository.
>>>
>>> Name: draft-ek-dtn-ethernet
>>> Revision: 00
>>> Title: Support for the Delay- and Disruption-Tolerant Networking (DTN)
>>> Bundle Protocol (BP) Datagrams over Ethernet
>>> Document date: 2023-07-10
>>> Group: Individual Submission
>>> Pages: 8
>>> URL: https://www.ietf.org/archive/id/draft-ek-dtn-ethernet-00.txt
>>> Status: https://datatracker.ietf.org/doc/draft-ek-dtn-ethernet/
>>> Html: https://www.ietf.org/archive/id/draft-ek-dtn-ethernet-00.html
>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ek-dtn-ethernet
>>>
>>>
>>> Abstract:
>>> This memo describes a mechanism for the transmission of Bundle
>>> Protocol (BP) Bundles over Ethernet links (BP-over-Ethernet),
>>> describes limitations and operational considerations, and requests
>>> some dedicated Ethernet parameters.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>