[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
- [6lo] Running 6lo on DECT-2020 NR+ Christian Amsüss
- [6lo] Re: Running 6lo on DECT-2020 NR+ Carles Gomez Montenegro