[6lo] Running 6lo on DECT-2020 NR+

Christian Amsüss <christian@amsuess.com> Tue, 04 November 2025 12:50 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: 6lo@mail2.ietf.org
Delivered-To: 6lo@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id AE2018268409 for <6lo@mail2.ietf.org>; Tue, 4 Nov 2025 04:50:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VSdXCd9KOlM for <6lo@mail2.ietf.org>; Tue, 4 Nov 2025 04:50:08 -0800 (PST)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 743CA826826B for <6lo@ietf.org>; Tue, 4 Nov 2025 04:50:01 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.18.1/8.18.1) with ESMTPS id 5A4CnrwM019112 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <6lo@ietf.org>; Tue, 4 Nov 2025 13:49:53 +0100 (CET) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (hermes.lan.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 163AC63C8F for <6lo@ietf.org>; Tue, 4 Nov 2025 13:49:53 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:3bc9:8d05:b7:ca0f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CF7BF53BAE for <6lo@ietf.org>; Tue, 4 Nov 2025 13:49:52 +0100 (CET)
Received: (nullmailer pid 1490892 invoked by uid 1000); Tue, 04 Nov 2025 12:49:52 -0000
Date: Tue, 04 Nov 2025 13:49:52 +0100
From: Christian Amsüss <christian@amsuess.com>
To: 6lo@ietf.org
Message-ID: <aQn2cAc7Cn9_DgGi@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="l8ywkLWnQaL1IdPN"
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.86
Message-ID-Hash: NKBTTYXSXN46RZT2FBQRJ56IN2DKI5UP
X-Message-ID-Hash: NKBTTYXSXN46RZT2FBQRJ56IN2DKI5UP
X-MailFrom: christian@amsuess.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-6lo.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [6lo] Running 6lo on DECT-2020 NR+
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Y0JNXjyrjpqCz9lwKk0FZd-Xvnk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Owner: <mailto:6lo-owner@ietf.org>
List-Post: <mailto:6lo@ietf.org>
List-Subscribe: <mailto:6lo-join@ietf.org>
List-Unsubscribe: <mailto:6lo-leave@ietf.org>

Hello 6lo group,

since RFC8105 has been published, ETSI has completed a new iteration of
the DECT standard, markeded as DECT-2020 NR+, technically ETSI TS
103-636-1 and -v5 (those are the IP-relevant ones), which unlike the ULE
used in 8105 merely coexists with (and is not part of the same stack as)
the classical DECT service.

Their codepoint allocations reserve an "endpoint value" (multiplex point
for different protocols) fo 0x8003 for compressed IPv6 datagrams
following RFC6282, but no document for details -- for example, RFC8105
talked about how their 40- and 20-bit addresses could or could not be
used, and what level of assembly is expected from the DECT layers. For
comparison, DECT-2020 uses long 32-bit and short 16-bit addresses (now
random), and hop-by-hop retransmission and fragmentation/reassembly.

While I think that some choices in how to actually do 6lo over DECT-2020
have obvious deductions from RFC8105, some (such as address
reconstruction or considerations for the DECT mesh) could need explicit
spelling-out.

Do you known of any public or WIP documents or efforts to fill those
gaps?

Best regards
Christian

[1]: https://portal.etsi.org/PNNS/Protocol-Specification-Allocation/DECT-2020-NR-Endpoint-Multiplexing-Addresses

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom