Re: [ipwave] Fwd: Re: [6lo] Call for feedback to draft-wachter-6lo-can-00

Alexander Wachter <> Mon, 28 October 2019 12:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0392512001E for <>; Mon, 28 Oct 2019 05:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LmJP7UArRhAc for <>; Mon, 28 Oct 2019 05:35:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55245120018 for <>; Mon, 28 Oct 2019 05:35:10 -0700 (PDT)
Received: (qmail 18630 invoked from network); 28 Oct 2019 12:35:08 -0000
Received: from localhost (HELO ? ( by with SMTP; 28 Oct 2019 12:35:08 -0000
To: Alexandre Petrescu <>,
References: <> <> <>
From: Alexander Wachter <>
Message-ID: <>
Date: Mon, 28 Oct 2019 13:36:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [ipwave] Fwd: Re: [6lo] Call for feedback to draft-wachter-6lo-can-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Oct 2019 12:35:13 -0000

Dear Alexandre,

On 28.10.19 13:03, Alexandre Petrescu wrote:
> Le 24/10/2019 à 16:42, Alexander Wachter a écrit :
> [...]
>>> I want to ask you whether you think that the end to end principle is 
>>> a good thing for the Internet, and if yes, whether Ethernet Border 
>>> Translators might have an impact on that principle.
>> The Ethernet Border Translator is optional for a 6LoCAN network.
>> I designed the Border Translator out of the lack of router 
>> capabilities of the Zephyr RTOS. This principle allows pushing 
>> complexity towards already existing network equipment and infrastructure.
> Could the Border Translator, with Zephyr RTOS, have a driver for an 
> 802.11-OCB card?  (preferably ath9k of Atheros).  This would make for a 
> great router for cars with many QoS-enabled applications.

Technically, the border translator works on Data-Link layers with a MAC 
address that is compatible with Ethernet and is capable of receiving a 
range of addresses (promiscuous mode, for example). For other Border 
Translators, 6LoCAN could be extended with rules, describing how to 
translate addresses.
Practically, no "RAW" WiFi drivers are implemented in Zephyr RTOS so far.
There are only WiFi drivers, who are offloading the network stack, where 
RAW packets cannot be forwarded.

> Alex
>> Sincerely,
>> Alexander
>>> Le 17/10/2019 à 17:25, Alexander Wachter a écrit :
>>>> Dear 6Lo WG,
>>>> I recently submitted a draft for IPv6 over Controller Area Network 
>>>> and would like to call for adoption by the 6Lo WG.
>>>> The title of the document is draft-wachter-6lo-can-00 [1].
>>>> Controller Area Network (CAN) is a widely used field bus initially 
>>>> designed for the automotive domain. It has a payload length of eight 
>>>> bytes for classic CAN and 64 bytes for CAN-FD. CAN only describes 
>>>> the data-link-layer, but various protocols already exist on top. The 
>>>> submitted draft introduces IPv6 over CAN (6LoCAN),  a 
>>>> 6lo-adaption-layer to send IPv6 packets over the constrained 
>>>> CAN-bus. 6LoCAN uses a subset of the already widely used ISO-TP 
>>>> standard for fragmentation and reassembly to meet the 1280 minimum 
>>>> MTU requirement of IPv6. It also uses the IPHC (RFC6282) to reduce 
>>>> the protocol overhead of IPv6.
>>>> A broad range of devices, from small and cheap MCUs to big 
>>>> application processors, already have CAN controllers onboard. With 
>>>> 6LoCAN, it is possible to create networks of resource-constrained 
>>>> MCUs that can leverage the broad range of protocols and security 
>>>> mechanisms built on top of the IP.
>>>> Additionally, multiple 6LoCAN networks can be connected together or 
>>>> even to the internet by utilizing the routing capabilities of IP 
>>>> networks.
>>>> A reference implementation of 6LoCAN already exists in the mainline 
>>>> Zephyrproject RTOS [2] tree. It includes a sample server-client 
>>>> application. The source for it is located under [3] and can be used 
>>>> on any boards supporting CAN.
>>>> I am looking forward to your comments on the draft.
>>>> Kind regards,
>>>> Alexander
>>>> [1]
>>>> [2]
>>>> [3] 

Alexander Wachter, BSc

Student of Information and Computer Engineering
Graz University of Technology