idnits 2.17.1 draft-wachter-6lo-can-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (17 October 2019) is 1652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group A. Wachter 3 Internet-Draft Graz University of Technology 4 Intended status: Standards Track 17 October 2019 5 Expires: 19 April 2020 7 IPv6 over Controller Area Network 8 draft-wachter-6lo-can-00 10 Abstract 12 Controller Area Network (CAN) is a fieldbus initially designed for 13 automotive applications. It is a multi-master bus with 11-bit or 14 29-bit frame identifiers. The CAN standard (ISO 11898 series) 15 defines the physical and data-link layer. This document describes 16 how to transfer IPv6 packets over CAN using ISO-TP, a dedicated 17 addressing scheme, and IP header compression (IPHC). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 19 April 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Controller Area Network Overview . . . . . . . . . . . . 3 55 1.3. ISO-TP Overview . . . . . . . . . . . . . . . . . . . . . 3 56 2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Address Generation . . . . . . . . . . . . . . . . . . . 6 60 3. Link-Layer Duplicate Address Detection . . . . . . . . . . . 6 61 4. Stateless Address Autoconfiguration . . . . . . . . . . . . . 7 62 5. IPv6 Link-Local Address . . . . . . . . . . . . . . . . . . . 8 63 6. ISO-TP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.2. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 10 67 6.4. Single-Frame . . . . . . . . . . . . . . . . . . . . . . 11 68 6.5. First-Frame . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.6. Consecutive-Frame . . . . . . . . . . . . . . . . . . . . 12 70 6.7. Flow-Control-Frame . . . . . . . . . . . . . . . . . . . 12 71 7. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 13 72 8. Ethernet Border Translator . . . . . . . . . . . . . . . . . 14 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 11. Reference Implementation . . . . . . . . . . . . . . . . . . 16 76 12. Normative References . . . . . . . . . . . . . . . . . . . . 16 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 Controller Area Network (CAN) is mostly known for its use in the 82 automotive domain. However, it is also used in industrial 83 applications as CANopen, building automation and many more. 85 It is a two-wire wired-AND multi-master bus that uses CSMA/CR in its 86 arbitration field. CAN uses 11-bit (standard ID) and 29-bit 87 (extended ID) identifiers to identify frames. The maximum payload 88 data size is 8 octets for classical CAN and 64 octets for CAN-FD. 90 The minimal MTU of IPv6 is 1280 octets, and therefore, a mechanism to 91 support a larger payload is needed. This document uses a slightly 92 modified version of the ISO-TP protocol to transfer data up to 4095 93 octets per packet. Mapping addresses to identifiers uses an 94 addressing scheme with a 14-bit source address, a 14-bit destination 95 address, and a multicast bit. This scheme uses extended identifiers 96 only. 98 To make data transfer more efficient IPHC [RFC6282] is used. 100 Due to the limited address space of 14 bits, random address 101 generation would generate duplicate addresses with an unacceptably 102 high probability. For this reason, a link-layer duplicate address 103 detection is introduced to resolve address conflicts. 105 An Ethernet border translator is designed to connect a 6LoCAN bus 106 segment to other networks. 108 1.1. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 1.2. Controller Area Network Overview 118 This section provides a brief overview of Controller Area Network 119 (CAN), as specified in [ISO 11898-1:2015]. CAN has two wires, CAN 120 High and CAN Low, where CAN High is tied to 5V and CAN Low to 0V when 121 transmitting a dominant (0) bit. Both wires are at the same level 122 (approximately 2.5V) when transmitting a recessive (1) bit. Because 123 of the wired-AND structure, a dominant bit overrides a recessive bit. 125 To resolve collisions in the arbitration field, a CAN controller 126 checks for overridden recessive bits. The sender that was sending 127 the recessive bit then stops the transmission. Therefore an 128 identifier with all zeros has the highest priority. 130 CAN controllers are usually able to filter frames by identifiers and 131 only pass frames where the filter matches. The identifiers can be 132 masked in order to define which bits of the identifier must match and 133 which ones are ignored. 135 1.3. ISO-TP Overview 137 A subset of ISO-TP (ISO 15765-2) is used to fragment and reassemble 138 the packets. This subset of ISO-TP can send packets with a payload 139 size of up to 4095 octets, enough for IPv6 minimum MTU size of 1280 140 octets. ISO-TP is designed for CAN and its small payload data size 141 and therefore preferred over [RFC4944] fragmentation. 143 The 6LoWPAN fragmentation would use more than the half of the 144 available payload for the fragmentation headers. This fact prevents 145 6LoWPAN fragmentation from being used for 6LoCAN. 147 2. Addressing 149 This section provides information about the 14-bit node address to 150 CAN identifier mapping. 152 Because CAN uses identifiers to identify the frame's content, an 153 addressing scheme is introduced to map node addresses to identifiers. 154 Every node has a unique 14-bit address. This address is assigned 155 either statically or randomly. The addressing scheme uses the 29-bit 156 extended identifier only. It is a combination of a source address, a 157 destination address, and a multicast bit. 159 The address 0x3DFE is reserved for link-layer duplicate address 160 detection, and address 0x3DF0 is reserved for the Ethernet border 161 translator. Addresses from 0x0100 to 0x3DEF are used as node 162 addresses. Other addresses (0x0000 to 0x00FF and 0x3DF0 to 0x3FFF) 163 are reserved or used for special purposes. Note that a lower address 164 number has a higher priority on the bus. 166 6LoCAN does not use the 11-bit standard identifiers. They may be 167 used for other purposes. 169 +-----------------+---------------------+ 170 | Address | Description | 171 +=================+=====================+ 172 | 0x3DFE - 0x3FFF | Reserved | 173 +-----------------+---------------------+ 174 | 0x3DFE | LLDAD | 175 +-----------------+---------------------+ 176 | 0x3DF1 - 0x3DFD | Reserved | 177 +-----------------+---------------------+ 178 | 0x3DF0 | Ethernet Translator | 179 +-----------------+---------------------+ 180 | 0x0100 - 0x3DEF | Node addresses | 181 +-----------------+---------------------+ 182 | 0x0000 - 0x00FF | Reserved | 183 +-----------------+---------------------+ 185 Table 1: Address ranges 187 0|0 1|1 2| 188 0|1 4|5 8| 189 +-+--------------+--------------+ 190 |M| DEST | SRC | 191 +-+--------------+--------------+ 193 Figure 1: Addressing Scheme 195 M : Multicast. 197 DEST : Destination Address (14 bits). 199 SRC : Source Address (14 bits). 201 For example, a destination of 0x3055 and source address of 0x3AAF 202 result in the following identifier: 204 0|0 1|1 2| 205 0|1 4|5 8| 206 +-+--------------+--------------+ 207 |0|11000001010101|11101010101111| 208 +-+--------------+--------------+ 210 Figure 2: Unicast identifier example 212 A multicast group of 1 and a source address of 0x3AAF result in the 213 following identifier: 215 0|0 1|1 2| 216 0|1 4|5 8| 217 +-+--------------+--------------+ 218 |1|00000000000001|11101010101111| 219 +-+--------------+--------------+ 221 Figure 3: Multicast identifier example 223 2.1. Unicast 225 For unicast packets, the multicast bit is set to zero, and the 14-bit 226 source address is the address of the sender. The 14-bit destination 227 address of the receiver is discovered by IPv6 NDP defined in 228 [RFC4861]. Every node MUST be able to receive all frames targeting 229 its address as the destination address. 231 2.2. Multicast 233 For multicast packets, the multicast bit is set to one, and the 234 14-bit source address is the address of the sender. The 14-bit 235 destination address is the last 14 bits of the multicast group. 236 Every node MUST be able to receive all frames matching the last 14 237 bits of all joined multicast groups as the destination address. 239 2.3. Address Generation 241 Every node has a 14-bit address. This address MUST be unique within 242 the CAN bus segment. The address can either be statically defined or 243 assigned randomly. For the random address assignment, the node tries 244 randomly chosen addresses until the link-layer duplicate address 245 detection succeeds. The link-layer duplicate address detection 246 prevents nodes from assigning an address already in use. 248 3. Link-Layer Duplicate Address Detection 250 This section provides information about how to perform link-layer 251 duplicate address detection (LLDAD). 253 LLDAD is introduced to prevent collisions of CAN identifiers and 254 makes it possible to use random address assignment with only 14 bits 255 of address space. To perform an LLDAD, a LLDAD-request is sent. If 256 there is no DAD-response sent back, the DAD is considered successful. 257 The node MUST wait for a response for at least 100ms. 259 LLDAD-requests are remote transmission request (RTR) frames with the 260 desired address as the destination and 14 bits entropy as the source 261 address. The entropy prevents identifier collisions when nodes are 262 trying to get the same address at the same time. 264 DAD-responses are data-frames sent to the LLDAD address (0x3DFE) with 265 the responder's address as the source address. Both LLDAD-request 266 and DAD-response have a data length of zero. 268 The node MUST be configured to receive RTR frames with the desired 269 address as the destination address before the LLDAD-request is sent 270 and frames with the LLDAD address as long as the LLDAD is in 271 progress. This prevents from assigning the same address to more than 272 one node when sending the LLDAD-request at the same time. The 273 ability to receive RTR frames with the desired address as the 274 destination address MUST be kept as long as the node uses the 275 address. The response to LLDAD-requests that matches the node 276 address MUST be sent before the requesting node stops waiting for the 277 response, which is 100ms. 279 Figure 4 shows a DAD Fail example where node A performs a LLDAD- 280 request on address 0x3055 where this address is already in use by 281 node B. 283 Node A Node B 284 |--LLDAD-request->| 285 | | 286 |<-LLDAD-response-| 288 LLDAD-request identifier: 289 This frame is a Remote Transmission Request (RTR) 290 |0|0 1|1 2| 291 |0|1 4|5 8| 292 +-+--------------+--------------+ 293 |0|11000001010101| entropy | 294 +-+--------------+--------------+ 296 DAD-response identifier: 297 |0|0 1|1 2| 298 |0|1 4|5 8| 299 +-+--------------+--------------+ 300 |0|11110111111110|11000001010101| 301 +-+--------------+--------------+ 303 Figure 4: DAD Fail example 305 4. Stateless Address Autoconfiguration 307 This section defines how to obtain an IPv6 Interface Identifier. 309 It is RECOMMENDED to form an IID derived from the node's address. 310 IIDs generated from the node address result in most efficient IPHC 311 header compression. However, IIDs MAY also be generated from other 312 sources. The general procedure for creating an IID is described in 313 Appendix A of [RFC4291], "Creating Modified EUI-64 Format Interface 314 Identifiers", as updated by [RFC7136]. 316 The Interface Identifier for link-local addresses SHOULD be formed by 317 concatenating the node's 14-bit address to the six octets 0x00, 0x00, 318 0x00, 0xFF, 0xFE, 0x00 and two bits 0b00. For example, an address of 319 hexadecimal value 0x3AAF results in the following IID: 321 |0 1|1 3|3 4|4 6| 322 |0 5|6 1|2 7|8 3| 323 +----------------+----------------+----------------+----------------+ 324 |0000000000000000|0000000011111111|1111111000000000|0011101010101111| 325 +----------------+----------------+----------------+----------------+ 327 Figure 5: IID from Address 0x3AAF 329 5. IPv6 Link-Local Address 331 The IPv6 link-local address [RFC4291] for a 6LoCAN interface is 332 formed by appending the Interface Identifier, as defined above, to 333 the prefix FE80::/64. 335 10 bits 54 bits 64 bits 336 +----------+-----------------------+----------------------------+ 337 |1111111010| (zeros) | Interface Identifier | 338 +----------+-----------------------+----------------------------+ 340 Figure 6: Link-Local address from IID 342 6. ISO-TP 344 This section provides information about the use of ISO-TP (ISO 345 15765-2) in this document. Parts of ISO-TP are used to provide a 346 reliable way for sending up to 4095 octets as a packet. It includes 347 a flow-control mechanism for unicast-packets and timeouts. 349 Multicast packets do not use any flow-control mechanism and are 350 therefore not covered by the ISO-TP standard. However, the 351 fragmentation and reassembly mechanism is still used for multicast 352 packets. 354 ISO-TP defines four different types of frames: Single-Frames (SF), 355 First-Frames (FF), Consecutive-Frames (CF), and Flow Control Frames 356 (FC). Single-Frames are used when the payload data size is small 357 enough to fit into a single CAN frame. For larger payload data 358 sizes, a First-Frame indicates the start of the message, Consecutive- 359 Frames carry the payload data and Flow Control Frames steer the 360 transmission. Network address extension and packet size larger than 361 4095 octets defined by ISO 15765-2 MUST NOT be used for 6LoCAN. 362 Single-Frame packets are only useful for CAN-FD because the eight 363 octets of classical CAN are too small for any IPv6 header. 365 6.1. Multicast 367 Multicast packets MUST be transferred in a Single-Frame when the 368 packet fits in a single frame. Multicast packets that are too big 369 for Single-Frames start with a First-Frame (FF). The FF contains 370 information about the entire payload data size and payload data bytes 371 to fill the rest of the remaining frame. The First-Frame is followed 372 by a break of 1 millisecond to allow the receivers to prepare for the 373 data reception. Consecutive-Frames carry the rest of the payload 374 data and a 4-bit sequence number to detect missing or out of order 375 frames. The number of Consecutive-Frames depends on the CAN frame 376 data size and the payload data size. Consecutive-Frames SHALL have 377 the maximum possible CAN data size. The last Consecutive-Frame may 378 have to include padding at the end. 380 Sender Multicast Listener 381 |-----FF---->| 382 | I 1 ms I | 383 |----CF 1--->| 384 |----CF 2--->| 385 | . | 386 | . | 387 |----CF n--->| 388 | | 390 Figure 7: Multicast packet sequence 392 6.2. Unicast 394 Unicast transfers use the same format for First-Frames and 395 Consecutive-Frames as the multicast transfer does. In contrast to 396 multicast, unicast transfers use Flow-Control-Frames to steer the 397 sender's behavior and signalize readiness. 399 The receiver can choose a block size and a minimum separation time 400 (ST min). 402 The block size (BS) defines how many frames are transmitted before 403 the sender MUST wait for another FC Frame. A zero BS is allowed and 404 denotes that the sender MUST NOT wait for another FC Frame. ST min 405 defines the minimal pause between the end of the previous frame and 406 the start of the next frame. The receiver MAY change BS and ST min 407 for following FC Frames. 409 The receiver MUST answer a FF within 1 second. After this timeout 410 the sender SHOULD abort and stop waiting for an FC frame. CF frames 411 MUST have a separation time less than or equal to one second. After 412 this timeout, a receiver SHOULD abort and stop waiting for CF. 413 Receivers and sender SHOULD handle more than one packet reception 414 from different peers at the same time. 416 Sender Receiver 417 |-----FF---->| 418 | | 419 |<----FC-----| 420 | | 421 |----CF 1--->| 422 | I ST min I | 423 |----CF 2--->| 424 | . | 425 | . | 426 |---CF BS--->| 427 | | 428 |<----FC-----| 429 | | 430 |--CF BS+1-->| 431 | I ST min I | 432 |--CF BS+2-->| 433 | . | 434 | . | 436 Figure 8: Unicast packet sequence. 438 6.3. Frame Format 440 The frame format of ISO-TP is described in this section. 442 The first 4 bits denote the Protocol Control Information (PCI). This 443 information is used to distinguish the different frame types. 445 |0 0|0 446 |0 3|4 447 +----+----- 448 |PCI | 449 +----+----- 451 Figure 9: ISO-TP Frame format 453 +--------+--------------------+ 454 | Number | Description | 455 +========+====================+ 456 | 0 | Single-Frame | 457 +--------+--------------------+ 458 | 1 | First-Frame | 459 +--------+--------------------+ 460 | 2 | Consecutive-Frame | 461 +--------+--------------------+ 462 | 3 | Flow-Control-Frame | 463 +--------+--------------------+ 464 | 4-15 | Reserved | 465 +--------+--------------------+ 467 Table 2: PCI Numbers 469 6.4. Single-Frame 471 The Single-Frame PCI is 0, and the rest of the octet is padded with 472 0. This format is compatible with ISO-TP with data size greater than 473 16 octets. 475 |0 0|0 0| 1|1 476 |0 3|4 7| 5|6 477 +----+----+--------+-------- 478 |0000|0000| Size | Data 479 +----+----+--------+-------- 481 Figure 10: Single-Frame Format 483 Size : Number of payload data octets. 485 6.5. First-Frame 487 The First-Frame PCI is 1, and the remaining 4-bit nibble of the first 488 byte carries the upper 4-bit nibble of the payload data length. The 489 second byte contains the lower byte of the payload data length. The 490 rest of the frame is filled with payload data. The First-Fame MUST 491 have a data length of the maximum CAN data length. For example, 492 classic CAN has a maximum data length of 8 octets, and therefore six 493 payload bytes are included in the FF. 495 |0 0|0 1|1 496 |0 3|4 5|6 497 +----+-------------+------- 498 |0001| Size | Data 499 +----+-------------+------- 500 Figure 11: First-Frame Format 502 Size : Number of payload data octets 504 6.6. Consecutive-Frame 506 The Consecutive-Frame PCI is two, and the remaining 4-bit nibble of 507 the first byte carries an index. This index starts with one for the 508 first CF and wraps around at 16. Then it starts at 0 again. The 509 index is used to check for lost or out of order frames. When the 510 index is not sequential, the reception MUST be aborted. The last 511 Consecutive-Frame may have to include padding at the end to obtain a 512 valid data length for CAN-FD frames. The RECOMMENDED padding value 513 is 0xCC. 515 |0 0|0 0|0 516 |0 3|4 7|8 517 +----+----+--------- 518 |0010|Idx | Data 519 +----+----+--------- 521 Figure 12: Consecutive-Frame Format 523 6.7. Flow-Control-Frame 525 The Flow-Control-Frame PCI is three, and the remaining 4-bit nibble 526 of the first byte carries a Flow-State (FS). The second byte is the 527 block size, and the third byte is the ST min. The Flow-States are: 529 +--------+------------------------+ 530 | Number | Description | 531 +========+========================+ 532 | 0 | CTS (Continue To Send) | 533 +--------+------------------------+ 534 | 1 | WAIT | 535 +--------+------------------------+ 536 | 2 | OVFLW (Overflow) | 537 +--------+------------------------+ 539 Table 3: Flow-State 541 CTS advises the sender to continue sending CF frames. 543 WAIT resets the timeout for receiving an FC frame on the sender side. 544 The sender SHOULD only accept a limited number of wait states and 545 silently abort when reaching the limit. 547 OVFLW is sent when the receiver is running out of resources and can't 548 handle the packet. The sender MUST abort when receiving an OVFLW 549 Flow-State. 551 |0 0|0 0| 1|1 2| 552 |0 3|4 7| 5|6 3| 553 +----+----+--------+--------+ 554 |0011| FS | BS | ST min | 555 +----+----+--------+--------+ 557 Figure 13: Flow-Control-Frame Format 559 FS : Frame State 561 BS : Block Size 563 ST min : Minimal Separation Time 565 7. Frame Format 567 This section provides information about data arrangement in the frame 568 data field. 570 +----------------------------+-------------------------------------+ 571 | ISO-TP Header (1-3 octets) | Dispatch + LOWPAN_IPHC (2-3 octets) | 572 +----------------------------+-------------+-----------------------+ 573 | In-line IPv6 Header Fields (0-38 octets) | Payload 574 +------------------------------------------+---------- 576 Figure 14: 6LoCAN Frame Format 578 Packets with a destination or source address of the 0x3DF0 579 (Translator address) carry the Ethernet MAC address inline directly 580 after the ISO-TP Header. For packets destined for the translator, it 581 is the destination MAC address, and for packets originated by the 582 translator, it is the source MAC address. 584 +----------------------------+--------------------------------+ 585 | ISO-TP Header (1-3 octets) | Ethernet MAC Address (48 bits) | 586 +----------------------------+-------+------------------------+ 587 | Dispatch + LOWPAN_IPHC (2-3 octets) | 588 +------------------------------------+-----+---------- 589 | In-line IPv6 Header Fields (0-38 octets) | Payload 590 +------------------------------------------+---------- 592 Figure 15: 6LoCAN Translator Frame Format 594 8. Ethernet Border Translator 596 This section provides information about translating 6LoCAN packets to 597 Ethernet frames. 599 The Ethernet Border Translator connects 6LoCAN bus-segments either to 600 other 6LoCAN bus-segments or other technologies. Ethernet is a 601 widely used technology that provides enough bandwidth to connect 602 several 6LoCAN segments. A mechanism like the 6LBR is not necessary 603 because there is no routing on 6LoCAN segments. To provide routing 604 or switching capabilities, the Ethernet Border Translator connects a 605 6LoCAN network to such devices via Ethernet. 607 Bus segments MUST NOT have more than one translator. The translator 608 has a fixed node address (0x3DF0) and a range of Ethernet MAC 609 addresses. Every packet sent to this node address or any multicast 610 address is forwarded to Ethernet. Every Ethernet frame matching the 611 MAC address range and every multicast Ethernet frame is forwarded to 612 the 6LoCAN bus-segment. 614 For translating a 6LoCAN packet to an Ethernet frame, the source 615 address is extended with the first 34 bits of the translator MAC 616 address and the IPHC compressed headers are decompressed. The 617 destination MAC is carried in-line before the compressed IPv6 header 618 (see Section 7, Figure 15). ICMPv6 messages MUST be checked for 619 Link-Layer Address Options (LLAO), and if an LLAO is present, it MUST 620 be changed to the extended link-layer address. For translating 621 Ethernet frames to 6LoCAN packets, the source MAC address is carried 622 in-line, the destination node address is the last 14 bits of the MAC 623 address, and the IPv6 headers are compressed using IPHC. 625 For multicast Ethernet frames, the last 14 bits of the multicast 626 group is the destination address, and the multicast bit is set. The 627 destination address MAY also be reconstructed from the destination 628 multicast address. The destination Ethernet MAC address is formed 629 from the destination IP address as described in [RFC2464] section 7. 631 If the translator includes a network stack, the translator MUST NOT 632 use a MAC address within the ranges used for translation, with the 633 following exception: The translator MAY use the extended MAC address 634 that corresponds to the translator node address. 636 Figure 18 shows an example setup of a 6LoCAN segment connected to an 637 Ethernet network. 639 Figure 16 shows a translation from Ethernet MAC to CAN identifier. 640 The source (src) MAC address is carried in-line in the CAN frame 641 data. The translator MAC address for this example is 642 02:00:5E:10:3D:F0. 644 |0 4|4 9 645 |0 7|8 5 646 +------------------------------+-------------------------------+ 647 | dest MAC (02:00:5E:10:30:55) | src MAC (02:00:5E:10:00:FF) | 648 +------------------------------+-------------------------------+ 649 Ethernet MAC 651 |0|0 1|1 2| 652 |0|1 4|5 8| 653 +-+--------------+--------------+ 654 |0|dest (0x3055) | src (0x3DF0) | 655 +-+--------------+--------------+ 656 CAN identifier 658 Figure 16: Example address translation from Ethernet MAC to CAN 659 identifier. 661 Figure 17 shows a translation from a multicast Ethernet MAC to CAN 662 identifier. The source MAC address is carried in-line in the CAN 663 frame data. 665 |0 4|4 9| 666 |0 7|8 5| 667 +------------------------------+-------------------------------+ 668 | dest MAC (33:33:00:01:00:01) | src MAC (02:00:5E:10:00:FF) | 669 +------------------------------+-------------------------------+ 670 Ethernet MAC 672 |0|0 1|1 2| 673 |0|1 4|5 8| 674 +-+--------------+--------------+ 675 |1|dest (0x0001) | src (0x3DF0) | 676 +-+--------------+--------------+ 677 CAN identifier 679 Figure 17: Example address translation from Ethernet to CAN for 680 multicast Frames. 682 Section 8 shows a translation CAN identifier to Ethernet MAC. The 683 destination (dest) MAC address is carried inline in the CAN frame 684 data. The translator MAC address for this example is 685 02:00:5E:10:3D:F0. 687 |0|0 1|1 2| 688 |0|1 4|5 8| 689 +-+--------------+--------------+ 690 |0|dest (0x3DF0) | src (0x3055) | 691 +-+--------------+--------------+ 692 CAN identifier 693 |0 4|4 9| 694 |0 7|8 5| 695 +------------------------------+-------------------------------+ 696 | dest MAC (02:00:5E:10:00:FF) | src MAC (02:00:5E:10:30:55) | 697 +------------------------------+-------------------------------+ 698 Ethernet MAC 700 +-----+ +-----+ 701 |CAN | |CAN | ... 702 |node | |node | 703 +--+--+ +--+--+ 704 +--------+---+ +---+----------+---+ | | 705 | | | | |Ethernet | | | | 706 | Switch |ETH|<--->|ETH|Border |CAN|------+--------+---- ... 707 | | | | |Translator| | 708 +--------+---+ +---+----------+---+ 710 Figure 18: Example setup with Ethernet Border Translator 712 9. IANA Considerations 714 The MAC addresses generated by extending the node's address may be 715 randomly generated and, therefore, MUST NOT set the UAA-bit. 717 10. Security Considerations 719 This document doesn't provide any security mechanisms. Traffic on 720 the bus can be intersected, spoofed, or destroyed. For 721 confidentiality and integrity, mechanisms like TLS or IPsec need to 722 be applied. 724 The small 14-bit node address space makes it hard to track nodes 725 globally and therefore has inherent privacy properties. 727 11. Reference Implementation 729 As a reference, this standard proposal is implemented in the Zephyr 730 RTOS from version 2.0 ongoing. This implementation can be tested 731 with the overlay-6locan.conf on echo_server and echo_client 732 application. 734 12. Normative References 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, 738 DOI 10.17487/RFC2119, March 1997, 739 . 741 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 742 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 743 . 745 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 746 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 747 2006, . 749 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 750 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 751 DOI 10.17487/RFC4861, September 2007, 752 . 754 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 755 "Transmission of IPv6 Packets over IEEE 802.15.4 756 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 757 . 759 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 760 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 761 DOI 10.17487/RFC6282, September 2011, 762 . 764 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 765 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 766 February 2014, . 768 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 769 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 770 May 2017, . 772 Author's Address 774 Alexander Wachter 775 Graz University of Technology 777 Email: alexander@wachter.cloud