Re: [6lo] Call for adoption of draft-wachter-6lo-can-00 by 6Lo WG

Alexandre Petrescu <> Mon, 21 October 2019 13:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C15F51200D5 for <>; Mon, 21 Oct 2019 06:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j7PJL8Bb-x1G for <>; Mon, 21 Oct 2019 06:56:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E59751200A3 for <>; Mon, 21 Oct 2019 06:56:02 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9LDu0D2002936 for <>; Mon, 21 Oct 2019 15:56:00 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id 52A4C20476A for <>; Mon, 21 Oct 2019 15:56:00 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 48EC7201E3D for <>; Mon, 21 Oct 2019 15:56:00 +0200 (CEST)
Received: from [] ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9LDu0Xt006210 for <>; Mon, 21 Oct 2019 15:56:00 +0200
References: <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Mon, 21 Oct 2019 15:56:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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: fr
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [6lo] Call for adoption of draft-wachter-6lo-can-00 by 6Lo WG
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Oct 2019 13:56:06 -0000


Might be appropriate to run this through the IPWAVE WG, too.

One question that comes to mind is how to make sure that the QoS of an 
IP packet on 802.11-OCB (wireless outside the car) is mapped to the 
right QoS of an IP packet on CAN inside the car.  This would help to 
send an IP packet from a Remote Controller straight into the brake of 
the car, with the appropriate priority and given the necessary credentials.

I want to ask you whether the CAN has a notion of CAN address and if 
yes, on how many bits is it represented (16?)?  This might help in 
thinking about how to form an Interface ID to be used with SLAAC on CAN. 
  One may think that should be 64bit, but I think not necessarily.

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.



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]