Internet-Draft 6LoCAN February 2020
Wachter Expires 30 August 2020 [Page]
Workgroup:
6Lo Working Group
Internet-Draft:
draft-wachter-6lo-can-01
Published:
Intended Status:
Standards Track
Expires:
Author:
A. Wachter
Graz University of Technology

IPv6 over Controller Area Network

Abstract

Controller Area Network (CAN) is a fieldbus initially designed for automotive applications. It is a multi-master bus with 11-bit or 29-bit frame identifiers. The CAN standard (ISO 11898 series) defines the physical and data-link layer. This document describes how to transfer IPv6 packets over CAN using ISO-TP, a dedicated addressing scheme, and IP header compression (IPHC).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 30 August 2020.

Table of Contents

1. Introduction

Controller Area Network (CAN) is mostly known for its use in the automotive domain. However, it is also used in industrial applications as CANopen, building automation and many more.

It is a two-wire wired-AND multi-master bus that uses CSMA/CR in its arbitration field. CAN uses 11-bit (standard ID) and 29-bit (extended ID) identifiers to identify frames. The arbitration field also incorporates a Remote Transmission Request (RTR), marking a frame as an RTR-frame. The maximum payload data size is 8 octets for classical CAN and 64 octets for CAN-FD.

The minimal MTU of IPv6 is 1280 octets, and therefore, a mechanism to support a larger payload is needed. This document uses a slightly modified version of the ISO-TP protocol to transfer data up to 4095 octets per packet. Mapping addresses to identifiers uses an addressing scheme with a 14-bit source address, a 14-bit destination address, and a multicast bit. This scheme uses extended identifiers only.

To make data transfer more efficient IPHC [RFC6282] is used.

Due to the limited address space of 14 bits, random address generation would generate duplicate addresses with an unacceptably high probability. For this reason, a link-layer duplicate address detection is introduced to resolve address conflicts.

An Ethernet border translator is designed to connect a 6LoCAN bus segment to other networks.

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.2. Controller Area Network Overview

This section provides a brief overview of Controller Area Network (CAN), as specified in [ISO 11898-1:2015]. CAN has two wires, CAN High and CAN Low, where CAN High is tied to 5V and CAN Low to 0V when transmitting a dominant (0) bit. Both wires are at the same level (approximately 2.5V) when transmitting a recessive (1) bit. Because of the wired-AND structure, a dominant bit overrides a recessive bit. The CAN specification does not define any structure for the identifier.

To resolve collisions in the arbitration field, a CAN controller checks for overridden recessive bits. The sender that was sending the recessive bit then stops the transmission. Therefore an identifier with all zeros has the highest priority.

CAN controllers are usually able to filter frames by identifiers and only pass frames where the filter matches. The identifiers can be masked in order to define which bits of the identifier must match and which ones are ignored.

1.3. ISO-TP Overview

A subset of ISO-TP (ISO 15765-2) is used to fragment and reassemble the packets. This subset of ISO-TP can send packets with a payload size of up to 4095 octets, enough for IPv6 minimum MTU size of 1280 octets. ISO-TP is designed for CAN and its small payload data size and therefore preferred over [RFC4944] fragmentation.

The 6LoWPAN fragmentation would use more than the half of the available payload for the fragmentation headers. This fact prevents 6LoWPAN fragmentation from being used for 6LoCAN.

2. Addressing

This section provides information about the 14-bit node address to CAN identifier mapping.

Because CAN uses identifiers to identify the frame's content, an addressing scheme is introduced to map node addresses to identifiers. Every node has a unique 14-bit address. This address is assigned either statically or randomly. The addressing scheme uses the 29-bit extended identifier only. It is a combination of a source address, a destination address, and a multicast bit. The multicast bit is at the highest bit-position, which causes the multicast traffic to have the lowest priority on the bus.

The address 0x3DFE is reserved for link-layer duplicate address detection, and address 0x3DF0 is reserved for the Ethernet border translator. Addresses from 0x0100 to 0x3DEF are used as node addresses. Other addresses (0x0000 to 0x00FF and 0x3DF0 to 0x3FFF) are reserved or used for special purposes. Note that a lower address number has a higher priority on the bus.

6LoCAN does not use the 11-bit standard identifiers. They may be used for other purposes.

Table 1: Address ranges
Address Description
0x3DFE - 0x3FFF Reserved
0x3DFE LLDAD
0x3DF1 - 0x3DFD Reserved
0x3DF0 Ethernet Translator
0x0100 - 0x3DEF Node addresses
0x0000 - 0x00FF Reserved
 0|0            1|1            2|
 0|1            4|5            8|
+-+--------------+--------------+
|M|     DEST     |     SRC      |
+-+--------------+--------------+
Figure 1: Addressing Scheme

M : Multicast.

DEST : Destination Address (14 bits).

SRC : Source Address (14 bits).

For example, a destination of 0x3055 and source address of 0x3AAF result in the following identifier:

 0|0            1|1            2|
 0|1            4|5            8|
+-+--------------+--------------+
|0|11000001010101|11101010101111|
+-+--------------+--------------+
Figure 2: Unicast identifier example

A multicast group of 1 and a source address of 0x3AAF result in the following identifier:

 0|0            1|1            2|
 0|1            4|5            8|
+-+--------------+--------------+
|1|00000000000001|11101010101111|
+-+--------------+--------------+
Figure 3: Multicast identifier example

2.1. Unicast

For unicast packets, the multicast bit is set to zero, and the 14-bit source address is the address of the sender. The 14-bit destination address of the receiver is discovered by IPv6 NDP defined in [RFC4861]. Every node MUST be able to receive all frames targeting its address as the destination address.

2.2. Multicast

For multicast packets, the multicast bit is set to one, and the 14-bit source address is the address of the sender. The 14-bit destination address is the last 14 bits of the multicast group. Every node MUST be able to receive all frames matching the last 14 bits of all joined multicast groups as the destination address.

2.3. Address Generation

Every node has a 14-bit address. This address MUST be unique within the CAN bus segment. The address can either be statically defined or assigned randomly. For the random address assignment, the node tries randomly chosen addresses until the link-layer duplicate address detection succeeds. The link-layer duplicate address detection prevents nodes from assigning an address already in use.

4. Stateless Address Autoconfiguration

This section defines how to obtain an IPv6 Interface Identifier.

It is RECOMMENDED to form an IID derived from the node's address. IIDs generated from the node address result in most efficient IPHC header compression. However, IIDs MAY also be generated from other sources. The general procedure for creating an IID is described in Appendix A of [RFC4291], "Creating Modified EUI-64 Format Interface Identifiers", as updated by [RFC7136].

The Interface Identifier for link-local addresses SHOULD be formed by taking the node address and zero fill it to the left. For example, an address of hexadecimal value 0x3AAF results in the following IID:

|0              1|1              3|3              4|4              6|
|0              5|6              1|2              7|8              3|
+----------------+----------------+----------------+----------------+
|0000000000000000|0000000000000000|0000000000000000|0011101010101111|
+----------------+----------------+----------------+----------------+
Figure 5: IID from Address 0x3AAF

6. ISO-TP

This section provides information about the use of ISO-TP (ISO 15765-2) in this document. Parts of ISO-TP are used to provide a reliable way for sending up to 4095 octets as a packet. It includes a flow-control mechanism for unicast-packets and timeouts.

Multicast packets do not use any flow-control mechanism and are therefore not covered by the ISO-TP standard. However, the fragmentation and reassembly mechanism is still used for multicast packets.

ISO-TP defines four different types of frames: Single-Frames (SF), First-Frames (FF), Consecutive-Frames (CF), and Flow Control Frames (FC). Single-Frames are used when the payload data size is small enough to fit into a single CAN frame. For larger payload data sizes, a First-Frame indicates the start of the message, Consecutive-Frames carry the payload data and Flow Control Frames steer the transmission. Network address extension and packet size larger than 4095 octets defined by ISO 15765-2 MUST NOT be used for 6LoCAN. Only CAN-FD Single-Frame packets are useful due to their payload size of up to 64 octets. Eight octet payload of classical CAN is too small to carry any IPv6 headers.

6.1. Multicast

Multicast packets MUST be transferred in a Single-Frame when the packet fits in a single frame. Multicast packets that are too big for Single-Frames start with a First-Frame (FF). The FF contains information about the entire payload data size and payload data bytes to fill the rest of the remaining frame. The First-Frame is followed by a break of 1 millisecond to allow the receivers to prepare for the data reception. Consecutive-Frames carry the rest of the payload data and a 4-bit sequence number to detect missing or out of order frames. The number of Consecutive-Frames depends on the CAN frame data size and the payload data size. Consecutive-Frames SHALL have the maximum possible CAN data size. The last Consecutive-Frame may have to include padding at the end.

Sender   Multicast Listener
  |-----FF---->|
  |  I 1 ms I  |
  |----CF 1--->|
  |----CF 2--->|
  |     .      |
  |     .      |
  |----CF n--->|
  |            |
Figure 7: Multicast packet sequence

6.2. Unicast

Unicast transfers use the same format for First-Frames and Consecutive-Frames as the multicast transfer does. In contrast to multicast, unicast transfers use Flow-Control-Frames to steer the sender's behavior and signalize readiness.

The receiver can choose a block size and a minimum separation time (ST min).

The block size (BS) defines how many frames are transmitted before the sender MUST wait for another FC Frame. A zero BS is allowed and denotes that the sender MUST NOT wait for another FC Frame. ST min defines the minimal pause between the end of the previous frame and the start of the next frame. The receiver MAY change BS and ST min for following FC Frames. It is RECOMMENDED to use a BS and ST min of zero if the node is capable of handling the load.

The receiver MUST answer a FF within 1 second. After this timeout the sender SHOULD abort and stop waiting for an FC frame. CF frames MUST have a separation time less than or equal to one second. After this timeout, a receiver SHOULD abort and stop waiting for CF. Receivers and sender SHOULD handle more than one packet reception from different peers at the same time.

Sender      Receiver
  |-----FF---->|
  |            |
  |<----FC-----|
  |            |
  |----CF 1--->|
  | I ST min I |
  |----CF 2--->|
  |      .     |
  |      .     |
  |---CF BS--->|
  |            |
  |<----FC-----|
  |            |
  |--CF BS+1-->|
  | I ST min I |
  |--CF BS+2-->|
  |      .     |
  |      .     |
Figure 8: Unicast packet sequence.

6.3. Frame Format

The frame format of ISO-TP is described in this section.

The first 4 bits denote the Protocol Control Information (PCI). This information is used to distinguish the different frame types.

|0  0|0
|0  3|4
+----+-----
|PCI |
+----+-----
Figure 9: ISO-TP Frame format
Table 2: PCI Numbers
Number Description
0 Single-Frame
1 First-Frame
2 Consecutive-Frame
3 Flow-Control-Frame
4-15 Reserved

6.4. Single-Frame

The Single-Frame PCI is 0, and the rest of the octet is padded with 0. This format is compatible with ISO-TP with data size greater than 16 octets.

|0  0|0  0|       1|1
|0  3|4  7|       5|6
+----+----+--------+--------
|0000|0000|  Size  | Data
+----+----+--------+--------
Figure 10: Single-Frame Format

Size : Number of payload data octets.

6.5. First-Frame

The First-Frame PCI is 1, and the remaining 4-bit nibble of the first byte carries the upper 4-bit nibble of the payload data length. The second byte contains the lower byte of the payload data length. The rest of the frame is filled with payload data. The First-Fame MUST have a data length of the maximum CAN data length. For example, classic CAN has a maximum data length of 8 octets, and therefore six payload bytes are included in the FF.

|0  0|0           1|1
|0  3|4           5|6
+----+-------------+-------
|0001|    Size     | Data
+----+-------------+-------
Figure 11: First-Frame Format

Size : Number of payload data octets

6.6. Consecutive-Frame

The Consecutive-Frame PCI is two, and the remaining 4-bit nibble of the first byte carries an index. This index starts with one for the first CF and wraps around at 16. Then it starts at 0 again. The index is used to check for lost or out of order frames. When the index is not sequential, the reception MUST be aborted. The last Consecutive-Frame may have to include padding at the end to obtain a valid data length for CAN-FD frames. The RECOMMENDED padding value is 0xCC.

|0  0|0  0|0
|0  3|4  7|8
+----+----+---------
|0010|Idx | Data
+----+----+---------
Figure 12: Consecutive-Frame Format

6.7. Flow-Control-Frame

The Flow-Control-Frame PCI is three, and the remaining 4-bit nibble of the first byte carries a Flow-State (FS). The second byte is the block size, and the third byte is the ST min. The Flow-States are:

Table 3: Flow-State
Number Description
0 CTS (Continue To Send)
1 WAIT
2 OVFLW (Overflow)

CTS advises the sender to continue sending CF frames.

WAIT resets the timeout for receiving an FC frame on the sender side. The sender SHOULD only accept a limited number of wait states and silently abort when reaching the limit.

OVFLW is sent when the receiver is running out of resources and can't handle the packet. The sender MUST abort when receiving an OVFLW Flow-State.

|0  0|0  0|       1|1      2|
|0  3|4  7|       5|6      3|
+----+----+--------+--------+
|0011| FS |   BS   | ST min |
+----+----+--------+--------+
Figure 13: Flow-Control-Frame Format

FS : Frame State

BS : Block Size

ST min : Minimal Separation Time

7. Frame Format

This section provides information about data arrangement in the frame data field.

The first byte(s) of the CAN frames always contains the ISO-TP header. For the first frame, the ISO-TP header is followed by the IPHC and in-line header fields. The IPHC and in-line might be spread over several frames. The payload data follows directly after.

+----------------------------+-------------------------------------+
| ISO-TP Header (1-3 octets) | Dispatch + LOWPAN_IPHC (2-3 octets) |
+----------------------------+-------------+-----------------------+
| In-line IPv6 Header Fields (0-38 octets) | Payload
+------------------------------------------+----------
Figure 14: 6LoCAN Frame Format

Packets with a destination or source address of the 0x3DF0 (Translator address) carry the Ethernet MAC address inline directly after the ISO-TP Header. For packets destined for the translator, it is the destination MAC address, and for packets originated by the translator, it is the source MAC address.

+----------------------------+--------------------------------+
| ISO-TP Header (1-3 octets) | Ethernet MAC Address (48 bits) |
+----------------------------+-------+------------------------+
| Dispatch + LOWPAN_IPHC (2-3 octets) |
+------------------------------------+-----+----------
| In-line IPv6 Header Fields (0-38 octets) | Payload
+------------------------------------------+----------
Figure 15: 6LoCAN Translator Frame Format

8. Ethernet Border Translator

This section provides information about translating 6LoCAN packets to Ethernet frames.

The Ethernet Border Translator connects 6LoCAN bus-segments either to other 6LoCAN bus-segments or other technologies. Ethernet is a widely used technology that provides enough bandwidth to connect several 6LoCAN segments. A mechanism like the 6LBR is not necessary because there is no routing on 6LoCAN segments. To provide routing or switching capabilities, the Ethernet Border Translator connects a 6LoCAN network to such devices via Ethernet.

Bus segments MUST NOT have more than one translator. The translator has a fixed node address (0x3DF0) and a range of Ethernet MAC addresses. Every packet sent to this node address or any multicast address is forwarded to Ethernet. Every Ethernet frame matching the MAC address range and every multicast Ethernet frame is forwarded to the 6LoCAN bus-segment.

For translating a 6LoCAN packet to an Ethernet frame, the source address is extended with a 34 bits MAC address prefix, and the IPHC compressed headers are decompressed. The 34 bits prefix MUST be chosen in a way that the resulting 48-bit MAC address forms a locally administered address that is unique on the link. The destination MAC is carried in-line before the compressed IPv6 header (see Section 7, Figure 15). ICMPv6 messages MUST be checked for Link-Layer Address Options (LLAO), and if an LLAO is present, it MUST be changed to the extended link-layer address. For translating Ethernet frames to 6LoCAN packets, the source MAC address is carried in-line, the destination node address is the last 14 bits of the MAC address, and the IPv6 headers are compressed using IPHC.

The Neighbor Caches of the networking stack must be able to store link-layer addresses with a size of 14 and 48 bits.

For multicast Ethernet frames, the last 14 bits of the multicast group is the destination address, and the multicast bit is set. The destination address MAY also be reconstructed from the destination multicast address. The destination Ethernet MAC address is formed from the destination IP address as described in [RFC2464] section 7.

If the translator includes a network stack, the translator MUST NOT use a MAC address within the ranges used for translation, with the following exception: The translator MAY use the extended MAC address that corresponds to the translator node address.

Figure 18 shows an example setup of a 6LoCAN segment connected to an Ethernet network.

Figure 16 shows a translation from Ethernet MAC to CAN identifier. The source (src) MAC address is carried in-line in the CAN frame data. The MAC address prefix for this example is 02:00:5E:10:00.

|0                            4|4                              9
|0                            7|8                              5
+------------------------------+-------------------------------+
| dest MAC (02:00:5E:10:30:55) |  src MAC (02:00:5E:10:00:FF)  |
+------------------------------+-------------------------------+
                          Ethernet MAC

|0|0            1|1            2|
|0|1            4|5            8|
+-+--------------+--------------+
|0|dest (0x3055) | src (0x3DF0) |
+-+--------------+--------------+
            CAN identifier
Figure 16: Example address translation from Ethernet MAC to CAN identifier.

Figure 17 shows a translation from a multicast Ethernet MAC to CAN identifier. The source MAC address is carried in-line in the CAN frame data.

|0                            4|4                             9|
|0                            7|8                             5|
+------------------------------+-------------------------------+
| dest MAC (33:33:00:01:00:01) |  src MAC (02:00:5E:10:00:FF)  |
+------------------------------+-------------------------------+
                          Ethernet MAC

|0|0            1|1            2|
|0|1            4|5            8|
+-+--------------+--------------+
|1|dest (0x0001) | src (0x3DF0) |
+-+--------------+--------------+
            CAN identifier
Figure 17: Example address translation from Ethernet to CAN for multicast Frames.

Section 8 shows a translation CAN identifier to Ethernet MAC. The destination (dest) MAC address is carried inline in the CAN frame data. The MAC address prefix for this example is 02:00:5E:10:00.

|0|0            1|1            2|
|0|1            4|5            8|
+-+--------------+--------------+
|0|dest (0x3DF0) | src (0x3055) |
+-+--------------+--------------+
            CAN identifier
|0                            4|4                             9|
|0                            7|8                             5|
+------------------------------+-------------------------------+
| dest MAC (02:00:5E:10:00:FF) |  src MAC (02:00:5E:10:30:55)  |
+------------------------------+-------------------------------+
                          Ethernet MAC
                                          +-----+  +-----+
                                          |CAN  |  |CAN  |  ...
                                          |node |  |node |
                                          +--+--+  +--+--+
+--------+---+     +---+----------+---+      |        |
|        |   |     |   |Ethernet  |   |      |        |
| Switch |ETH|<--->|ETH|Border    |CAN|------+--------+---- ...
|        |   |     |   |Translator|   |
+--------+---+     +---+----------+---+
Figure 18: Example setup with Ethernet Border Translator

9. IANA Considerations

The MAC addresses generated by extending the node's address may be randomly generated and, therefore, MUST NOT set the UAA-bit.

10. Security Considerations

This document doesn't provide any security mechanisms. Traffic on the bus can be intersected, spoofed, or destroyed. For confidentiality and integrity, mechanisms like TLS or IPsec need to be applied.

The small 14-bit node address space makes it hard to track nodes globally and therefore has inherent privacy properties.

11. Reference Implementation

As a reference, this standard proposal is implemented in the Zephyr RTOS from version 2.0 ongoing. This implementation can be tested with the overlay-6locan.conf on echoserver and echoclient application.

12. Normative References

[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC4944]
Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, , <https://www.rfc-editor.org/info/rfc4944>.
[RFC4861]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <https://www.rfc-editor.org/info/rfc4861>.
[RFC4291]
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <https://www.rfc-editor.org/info/rfc4291>.
[RFC7136]
Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, , <https://www.rfc-editor.org/info/rfc7136>.
[RFC2464]
Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, , <https://www.rfc-editor.org/info/rfc2464>.
[RFC6282]
Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, , <https://www.rfc-editor.org/info/rfc6282>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.

Author's Address

Alexander Wachter
Graz University of Technology