idnits 2.17.1 draft-wachter-6lo-can-01.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 (27 February 2020) is 1520 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 27 February 2020 5 Expires: 30 August 2020 7 IPv6 over Controller Area Network 8 draft-wachter-6lo-can-01 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 30 August 2020. 36 Copyright Notice 38 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . 4 56 2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 17 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 11. Reference Implementation . . . . . . . . . . . . . . . . . . 17 76 12. Normative References . . . . . . . . . . . . . . . . . . . . 17 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 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 arbitration field 88 also incorporates a Remote Transmission Request (RTR), marking a 89 frame as an RTR-frame. The maximum payload data size is 8 octets for 90 classical CAN and 64 octets for CAN-FD. 92 The minimal MTU of IPv6 is 1280 octets, and therefore, a mechanism to 93 support a larger payload is needed. This document uses a slightly 94 modified version of the ISO-TP protocol to transfer data up to 4095 95 octets per packet. Mapping addresses to identifiers uses an 96 addressing scheme with a 14-bit source address, a 14-bit destination 97 address, and a multicast bit. This scheme uses extended identifiers 98 only. 100 To make data transfer more efficient IPHC [RFC6282] is used. 102 Due to the limited address space of 14 bits, random address 103 generation would generate duplicate addresses with an unacceptably 104 high probability. For this reason, a link-layer duplicate address 105 detection is introduced to resolve address conflicts. 107 An Ethernet border translator is designed to connect a 6LoCAN bus 108 segment to other networks. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 1.2. Controller Area Network Overview 120 This section provides a brief overview of Controller Area Network 121 (CAN), as specified in [ISO 11898-1:2015]. CAN has two wires, CAN 122 High and CAN Low, where CAN High is tied to 5V and CAN Low to 0V when 123 transmitting a dominant (0) bit. Both wires are at the same level 124 (approximately 2.5V) when transmitting a recessive (1) bit. Because 125 of the wired-AND structure, a dominant bit overrides a recessive bit. 126 The CAN specification does not define any structure for the 127 identifier. 129 To resolve collisions in the arbitration field, a CAN controller 130 checks for overridden recessive bits. The sender that was sending 131 the recessive bit then stops the transmission. Therefore an 132 identifier with all zeros has the highest priority. 134 CAN controllers are usually able to filter frames by identifiers and 135 only pass frames where the filter matches. The identifiers can be 136 masked in order to define which bits of the identifier must match and 137 which ones are ignored. 139 1.3. ISO-TP Overview 141 A subset of ISO-TP (ISO 15765-2) is used to fragment and reassemble 142 the packets. This subset of ISO-TP can send packets with a payload 143 size of up to 4095 octets, enough for IPv6 minimum MTU size of 1280 144 octets. ISO-TP is designed for CAN and its small payload data size 145 and therefore preferred over [RFC4944] fragmentation. 147 The 6LoWPAN fragmentation would use more than the half of the 148 available payload for the fragmentation headers. This fact prevents 149 6LoWPAN fragmentation from being used for 6LoCAN. 151 2. Addressing 153 This section provides information about the 14-bit node address to 154 CAN identifier mapping. 156 Because CAN uses identifiers to identify the frame's content, an 157 addressing scheme is introduced to map node addresses to identifiers. 158 Every node has a unique 14-bit address. This address is assigned 159 either statically or randomly. The addressing scheme uses the 29-bit 160 extended identifier only. It is a combination of a source address, a 161 destination address, and a multicast bit. The multicast bit is at 162 the highest bit-position, which causes the multicast traffic to have 163 the lowest priority on the bus. 165 The address 0x3DFE is reserved for link-layer duplicate address 166 detection, and address 0x3DF0 is reserved for the Ethernet border 167 translator. Addresses from 0x0100 to 0x3DEF are used as node 168 addresses. Other addresses (0x0000 to 0x00FF and 0x3DF0 to 0x3FFF) 169 are reserved or used for special purposes. Note that a lower address 170 number has a higher priority on the bus. 172 6LoCAN does not use the 11-bit standard identifiers. They may be 173 used for other purposes. 175 +-----------------+---------------------+ 176 | Address | Description | 177 +=================+=====================+ 178 | 0x3DFE - 0x3FFF | Reserved | 179 +-----------------+---------------------+ 180 | 0x3DFE | LLDAD | 181 +-----------------+---------------------+ 182 | 0x3DF1 - 0x3DFD | Reserved | 183 +-----------------+---------------------+ 184 | 0x3DF0 | Ethernet Translator | 185 +-----------------+---------------------+ 186 | 0x0100 - 0x3DEF | Node addresses | 187 +-----------------+---------------------+ 188 | 0x0000 - 0x00FF | Reserved | 189 +-----------------+---------------------+ 191 Table 1: Address ranges 193 0|0 1|1 2| 194 0|1 4|5 8| 195 +-+--------------+--------------+ 196 |M| DEST | SRC | 197 +-+--------------+--------------+ 199 Figure 1: Addressing Scheme 201 M : Multicast. 203 DEST : Destination Address (14 bits). 205 SRC : Source Address (14 bits). 207 For example, a destination of 0x3055 and source address of 0x3AAF 208 result in the following identifier: 210 0|0 1|1 2| 211 0|1 4|5 8| 212 +-+--------------+--------------+ 213 |0|11000001010101|11101010101111| 214 +-+--------------+--------------+ 216 Figure 2: Unicast identifier example 218 A multicast group of 1 and a source address of 0x3AAF result in the 219 following identifier: 221 0|0 1|1 2| 222 0|1 4|5 8| 223 +-+--------------+--------------+ 224 |1|00000000000001|11101010101111| 225 +-+--------------+--------------+ 227 Figure 3: Multicast identifier example 229 2.1. Unicast 231 For unicast packets, the multicast bit is set to zero, and the 14-bit 232 source address is the address of the sender. The 14-bit destination 233 address of the receiver is discovered by IPv6 NDP defined in 234 [RFC4861]. Every node MUST be able to receive all frames targeting 235 its address as the destination address. 237 2.2. Multicast 239 For multicast packets, the multicast bit is set to one, and the 240 14-bit source address is the address of the sender. The 14-bit 241 destination address is the last 14 bits of the multicast group. 242 Every node MUST be able to receive all frames matching the last 14 243 bits of all joined multicast groups as the destination address. 245 2.3. Address Generation 247 Every node has a 14-bit address. This address MUST be unique within 248 the CAN bus segment. The address can either be statically defined or 249 assigned randomly. For the random address assignment, the node tries 250 randomly chosen addresses until the link-layer duplicate address 251 detection succeeds. The link-layer duplicate address detection 252 prevents nodes from assigning an address already in use. 254 3. Link-Layer Duplicate Address Detection 256 This section provides information about how to perform link-layer 257 duplicate address detection (LLDAD). 259 LLDAD is introduced to prevent collisions of CAN identifiers and 260 makes it possible to use random address assignment with only 14 bits 261 of address space. To perform an LLDAD, a LLDAD-request is sent. If 262 there is no DAD-response sent back, the DAD is considered successful. 263 The node MUST wait for a response for at least 100ms. 265 LLDAD-requests are remote transmission request (RTR) frames with the 266 desired address as the destination and 14 bits entropy as the source 267 address. The entropy prevents identifier collisions when nodes are 268 trying to get the same address at the same time. 270 DAD-responses are data-frames sent to the LLDAD address (0x3DFE) with 271 the responder's address as the source address. Both LLDAD-request 272 and DAD-response have a data length of zero. 274 The node MUST be configured to receive RTR frames with the desired 275 address as the destination address before the LLDAD-request is sent 276 and frames with the LLDAD address as long as the LLDAD is in 277 progress. This prevents from assigning the same address to more than 278 one node when sending the LLDAD-request at the same time. The 279 ability to receive RTR frames with the desired address as the 280 destination address MUST be kept as long as the node uses the 281 address. The response to LLDAD-requests that matches the node 282 address MUST be sent before the requesting node stops waiting for the 283 response, which is 100ms. 285 Figure 4 shows a DAD Fail example where node A performs a LLDAD- 286 request on address 0x3055 where this address is already in use by 287 node B. 289 Node A Node B 290 |--LLDAD-request->| 291 | | 292 |<-LLDAD-response-| 294 LLDAD-request identifier: 295 This frame is a Remote Transmission Request (RTR) 296 |0|0 1|1 2| 297 |0|1 4|5 8| 298 +-+--------------+--------------+ 299 |0|11000001010101| entropy | 300 +-+--------------+--------------+ 302 DAD-response identifier: 303 |0|0 1|1 2| 304 |0|1 4|5 8| 305 +-+--------------+--------------+ 306 |0|11110111111110|11000001010101| 307 +-+--------------+--------------+ 309 Figure 4: DAD Fail example 311 4. Stateless Address Autoconfiguration 313 This section defines how to obtain an IPv6 Interface Identifier. 315 It is RECOMMENDED to form an IID derived from the node's address. 316 IIDs generated from the node address result in most efficient IPHC 317 header compression. However, IIDs MAY also be generated from other 318 sources. The general procedure for creating an IID is described in 319 Appendix A of [RFC4291], "Creating Modified EUI-64 Format Interface 320 Identifiers", as updated by [RFC7136]. 322 The Interface Identifier for link-local addresses SHOULD be formed by 323 taking the node address and zero fill it to the left. For example, 324 an address of hexadecimal value 0x3AAF results in the following IID: 326 |0 1|1 3|3 4|4 6| 327 |0 5|6 1|2 7|8 3| 328 +----------------+----------------+----------------+----------------+ 329 |0000000000000000|0000000000000000|0000000000000000|0011101010101111| 330 +----------------+----------------+----------------+----------------+ 332 Figure 5: IID from Address 0x3AAF 334 5. IPv6 Link-Local Address 336 The IPv6 link-local address [RFC4291] for a 6LoCAN interface is 337 formed by appending the Interface Identifier, as defined above, to 338 the prefix FE80::/64. 340 10 bits 54 bits 64 bits 341 +----------+-----------------------+----------------------------+ 342 |1111111010| (zeros) | Interface Identifier | 343 +----------+-----------------------+----------------------------+ 345 Figure 6: Link-Local address from IID 347 6. ISO-TP 349 This section provides information about the use of ISO-TP (ISO 350 15765-2) in this document. Parts of ISO-TP are used to provide a 351 reliable way for sending up to 4095 octets as a packet. It includes 352 a flow-control mechanism for unicast-packets and timeouts. 354 Multicast packets do not use any flow-control mechanism and are 355 therefore not covered by the ISO-TP standard. However, the 356 fragmentation and reassembly mechanism is still used for multicast 357 packets. 359 ISO-TP defines four different types of frames: Single-Frames (SF), 360 First-Frames (FF), Consecutive-Frames (CF), and Flow Control Frames 361 (FC). Single-Frames are used when the payload data size is small 362 enough to fit into a single CAN frame. For larger payload data 363 sizes, a First-Frame indicates the start of the message, Consecutive- 364 Frames carry the payload data and Flow Control Frames steer the 365 transmission. Network address extension and packet size larger than 366 4095 octets defined by ISO 15765-2 MUST NOT be used for 6LoCAN. Only 367 CAN-FD Single-Frame packets are useful due to their payload size of 368 up to 64 octets. Eight octet payload of classical CAN is too small 369 to carry any IPv6 headers. 371 6.1. Multicast 373 Multicast packets MUST be transferred in a Single-Frame when the 374 packet fits in a single frame. Multicast packets that are too big 375 for Single-Frames start with a First-Frame (FF). The FF contains 376 information about the entire payload data size and payload data bytes 377 to fill the rest of the remaining frame. The First-Frame is followed 378 by a break of 1 millisecond to allow the receivers to prepare for the 379 data reception. Consecutive-Frames carry the rest of the payload 380 data and a 4-bit sequence number to detect missing or out of order 381 frames. The number of Consecutive-Frames depends on the CAN frame 382 data size and the payload data size. Consecutive-Frames SHALL have 383 the maximum possible CAN data size. The last Consecutive-Frame may 384 have to include padding at the end. 386 Sender Multicast Listener 387 |-----FF---->| 388 | I 1 ms I | 389 |----CF 1--->| 390 |----CF 2--->| 391 | . | 392 | . | 393 |----CF n--->| 394 | | 396 Figure 7: Multicast packet sequence 398 6.2. Unicast 400 Unicast transfers use the same format for First-Frames and 401 Consecutive-Frames as the multicast transfer does. In contrast to 402 multicast, unicast transfers use Flow-Control-Frames to steer the 403 sender's behavior and signalize readiness. 405 The receiver can choose a block size and a minimum separation time 406 (ST min). 408 The block size (BS) defines how many frames are transmitted before 409 the sender MUST wait for another FC Frame. A zero BS is allowed and 410 denotes that the sender MUST NOT wait for another FC Frame. ST min 411 defines the minimal pause between the end of the previous frame and 412 the start of the next frame. The receiver MAY change BS and ST min 413 for following FC Frames. It is RECOMMENDED to use a BS and ST min of 414 zero if the node is capable of handling the load. 416 The receiver MUST answer a FF within 1 second. After this timeout 417 the sender SHOULD abort and stop waiting for an FC frame. CF frames 418 MUST have a separation time less than or equal to one second. After 419 this timeout, a receiver SHOULD abort and stop waiting for CF. 420 Receivers and sender SHOULD handle more than one packet reception 421 from different peers at the same time. 423 Sender Receiver 424 |-----FF---->| 425 | | 426 |<----FC-----| 427 | | 428 |----CF 1--->| 429 | I ST min I | 430 |----CF 2--->| 431 | . | 432 | . | 433 |---CF BS--->| 434 | | 435 |<----FC-----| 436 | | 437 |--CF BS+1-->| 438 | I ST min I | 439 |--CF BS+2-->| 440 | . | 441 | . | 443 Figure 8: Unicast packet sequence. 445 6.3. Frame Format 447 The frame format of ISO-TP is described in this section. 449 The first 4 bits denote the Protocol Control Information (PCI). This 450 information is used to distinguish the different frame types. 452 |0 0|0 453 |0 3|4 454 +----+----- 455 |PCI | 456 +----+----- 458 Figure 9: ISO-TP Frame format 460 +--------+--------------------+ 461 | Number | Description | 462 +========+====================+ 463 | 0 | Single-Frame | 464 +--------+--------------------+ 465 | 1 | First-Frame | 466 +--------+--------------------+ 467 | 2 | Consecutive-Frame | 468 +--------+--------------------+ 469 | 3 | Flow-Control-Frame | 470 +--------+--------------------+ 471 | 4-15 | Reserved | 472 +--------+--------------------+ 474 Table 2: PCI Numbers 476 6.4. Single-Frame 478 The Single-Frame PCI is 0, and the rest of the octet is padded with 479 0. This format is compatible with ISO-TP with data size greater than 480 16 octets. 482 |0 0|0 0| 1|1 483 |0 3|4 7| 5|6 484 +----+----+--------+-------- 485 |0000|0000| Size | Data 486 +----+----+--------+-------- 488 Figure 10: Single-Frame Format 490 Size : Number of payload data octets. 492 6.5. First-Frame 494 The First-Frame PCI is 1, and the remaining 4-bit nibble of the first 495 byte carries the upper 4-bit nibble of the payload data length. The 496 second byte contains the lower byte of the payload data length. The 497 rest of the frame is filled with payload data. The First-Fame MUST 498 have a data length of the maximum CAN data length. For example, 499 classic CAN has a maximum data length of 8 octets, and therefore six 500 payload bytes are included in the FF. 502 |0 0|0 1|1 503 |0 3|4 5|6 504 +----+-------------+------- 505 |0001| Size | Data 506 +----+-------------+------- 507 Figure 11: First-Frame Format 509 Size : Number of payload data octets 511 6.6. Consecutive-Frame 513 The Consecutive-Frame PCI is two, and the remaining 4-bit nibble of 514 the first byte carries an index. This index starts with one for the 515 first CF and wraps around at 16. Then it starts at 0 again. The 516 index is used to check for lost or out of order frames. When the 517 index is not sequential, the reception MUST be aborted. The last 518 Consecutive-Frame may have to include padding at the end to obtain a 519 valid data length for CAN-FD frames. The RECOMMENDED padding value 520 is 0xCC. 522 |0 0|0 0|0 523 |0 3|4 7|8 524 +----+----+--------- 525 |0010|Idx | Data 526 +----+----+--------- 528 Figure 12: Consecutive-Frame Format 530 6.7. Flow-Control-Frame 532 The Flow-Control-Frame PCI is three, and the remaining 4-bit nibble 533 of the first byte carries a Flow-State (FS). The second byte is the 534 block size, and the third byte is the ST min. The Flow-States are: 536 +--------+------------------------+ 537 | Number | Description | 538 +========+========================+ 539 | 0 | CTS (Continue To Send) | 540 +--------+------------------------+ 541 | 1 | WAIT | 542 +--------+------------------------+ 543 | 2 | OVFLW (Overflow) | 544 +--------+------------------------+ 546 Table 3: Flow-State 548 CTS advises the sender to continue sending CF frames. 550 WAIT resets the timeout for receiving an FC frame on the sender side. 551 The sender SHOULD only accept a limited number of wait states and 552 silently abort when reaching the limit. 554 OVFLW is sent when the receiver is running out of resources and can't 555 handle the packet. The sender MUST abort when receiving an OVFLW 556 Flow-State. 558 |0 0|0 0| 1|1 2| 559 |0 3|4 7| 5|6 3| 560 +----+----+--------+--------+ 561 |0011| FS | BS | ST min | 562 +----+----+--------+--------+ 564 Figure 13: Flow-Control-Frame Format 566 FS : Frame State 568 BS : Block Size 570 ST min : Minimal Separation Time 572 7. Frame Format 574 This section provides information about data arrangement in the frame 575 data field. 577 The first byte(s) of the CAN frames always contains the ISO-TP 578 header. For the first frame, the ISO-TP header is followed by the 579 IPHC and in-line header fields. The IPHC and in-line might be spread 580 over several frames. The payload data follows directly after. 582 +----------------------------+-------------------------------------+ 583 | ISO-TP Header (1-3 octets) | Dispatch + LOWPAN_IPHC (2-3 octets) | 584 +----------------------------+-------------+-----------------------+ 585 | In-line IPv6 Header Fields (0-38 octets) | Payload 586 +------------------------------------------+---------- 588 Figure 14: 6LoCAN Frame Format 590 Packets with a destination or source address of the 0x3DF0 591 (Translator address) carry the Ethernet MAC address inline directly 592 after the ISO-TP Header. For packets destined for the translator, it 593 is the destination MAC address, and for packets originated by the 594 translator, it is the source MAC address. 596 +----------------------------+--------------------------------+ 597 | ISO-TP Header (1-3 octets) | Ethernet MAC Address (48 bits) | 598 +----------------------------+-------+------------------------+ 599 | Dispatch + LOWPAN_IPHC (2-3 octets) | 600 +------------------------------------+-----+---------- 601 | In-line IPv6 Header Fields (0-38 octets) | Payload 602 +------------------------------------------+---------- 604 Figure 15: 6LoCAN Translator Frame Format 606 8. Ethernet Border Translator 608 This section provides information about translating 6LoCAN packets to 609 Ethernet frames. 611 The Ethernet Border Translator connects 6LoCAN bus-segments either to 612 other 6LoCAN bus-segments or other technologies. Ethernet is a 613 widely used technology that provides enough bandwidth to connect 614 several 6LoCAN segments. A mechanism like the 6LBR is not necessary 615 because there is no routing on 6LoCAN segments. To provide routing 616 or switching capabilities, the Ethernet Border Translator connects a 617 6LoCAN network to such devices via Ethernet. 619 Bus segments MUST NOT have more than one translator. The translator 620 has a fixed node address (0x3DF0) and a range of Ethernet MAC 621 addresses. Every packet sent to this node address or any multicast 622 address is forwarded to Ethernet. Every Ethernet frame matching the 623 MAC address range and every multicast Ethernet frame is forwarded to 624 the 6LoCAN bus-segment. 626 For translating a 6LoCAN packet to an Ethernet frame, the source 627 address is extended with a 34 bits MAC address prefix, and the IPHC 628 compressed headers are decompressed. The 34 bits prefix MUST be 629 chosen in a way that the resulting 48-bit MAC address forms a locally 630 administered address that is unique on the link. The destination MAC 631 is carried in-line before the compressed IPv6 header (see Section 7, 632 Figure 15). ICMPv6 messages MUST be checked for Link-Layer Address 633 Options (LLAO), and if an LLAO is present, it MUST be changed to the 634 extended link-layer address. For translating Ethernet frames to 635 6LoCAN packets, the source MAC address is carried in-line, the 636 destination node address is the last 14 bits of the MAC address, and 637 the IPv6 headers are compressed using IPHC. 639 The Neighbor Caches of the networking stack must be able to store 640 link-layer addresses with a size of 14 and 48 bits. 642 For multicast Ethernet frames, the last 14 bits of the multicast 643 group is the destination address, and the multicast bit is set. The 644 destination address MAY also be reconstructed from the destination 645 multicast address. The destination Ethernet MAC address is formed 646 from the destination IP address as described in [RFC2464] section 7. 648 If the translator includes a network stack, the translator MUST NOT 649 use a MAC address within the ranges used for translation, with the 650 following exception: The translator MAY use the extended MAC address 651 that corresponds to the translator node address. 653 Figure 18 shows an example setup of a 6LoCAN segment connected to an 654 Ethernet network. 656 Figure 16 shows a translation from Ethernet MAC to CAN identifier. 657 The source (src) MAC address is carried in-line in the CAN frame 658 data. The MAC address prefix for this example is 02:00:5E:10:00. 660 |0 4|4 9 661 |0 7|8 5 662 +------------------------------+-------------------------------+ 663 | dest MAC (02:00:5E:10:30:55) | src MAC (02:00:5E:10:00:FF) | 664 +------------------------------+-------------------------------+ 665 Ethernet MAC 667 |0|0 1|1 2| 668 |0|1 4|5 8| 669 +-+--------------+--------------+ 670 |0|dest (0x3055) | src (0x3DF0) | 671 +-+--------------+--------------+ 672 CAN identifier 674 Figure 16: Example address translation from Ethernet MAC to CAN 675 identifier. 677 Figure 17 shows a translation from a multicast Ethernet MAC to CAN 678 identifier. The source MAC address is carried in-line in the CAN 679 frame data. 681 |0 4|4 9| 682 |0 7|8 5| 683 +------------------------------+-------------------------------+ 684 | dest MAC (33:33:00:01:00:01) | src MAC (02:00:5E:10:00:FF) | 685 +------------------------------+-------------------------------+ 686 Ethernet MAC 688 |0|0 1|1 2| 689 |0|1 4|5 8| 690 +-+--------------+--------------+ 691 |1|dest (0x0001) | src (0x3DF0) | 692 +-+--------------+--------------+ 693 CAN identifier 695 Figure 17: Example address translation from Ethernet to CAN for 696 multicast Frames. 698 Section 8 shows a translation CAN identifier to Ethernet MAC. The 699 destination (dest) MAC address is carried inline in the CAN frame 700 data. The MAC address prefix for this example is 02:00:5E:10:00. 702 |0|0 1|1 2| 703 |0|1 4|5 8| 704 +-+--------------+--------------+ 705 |0|dest (0x3DF0) | src (0x3055) | 706 +-+--------------+--------------+ 707 CAN identifier 708 |0 4|4 9| 709 |0 7|8 5| 710 +------------------------------+-------------------------------+ 711 | dest MAC (02:00:5E:10:00:FF) | src MAC (02:00:5E:10:30:55) | 712 +------------------------------+-------------------------------+ 713 Ethernet MAC 715 +-----+ +-----+ 716 |CAN | |CAN | ... 717 |node | |node | 718 +--+--+ +--+--+ 719 +--------+---+ +---+----------+---+ | | 720 | | | | |Ethernet | | | | 721 | Switch |ETH|<--->|ETH|Border |CAN|------+--------+---- ... 722 | | | | |Translator| | 723 +--------+---+ +---+----------+---+ 725 Figure 18: Example setup with Ethernet Border Translator 727 9. IANA Considerations 729 The MAC addresses generated by extending the node's address may be 730 randomly generated and, therefore, MUST NOT set the UAA-bit. 732 10. Security Considerations 734 This document doesn't provide any security mechanisms. Traffic on 735 the bus can be intersected, spoofed, or destroyed. For 736 confidentiality and integrity, mechanisms like TLS or IPsec need to 737 be applied. 739 The small 14-bit node address space makes it hard to track nodes 740 globally and therefore has inherent privacy properties. 742 11. Reference Implementation 744 As a reference, this standard proposal is implemented in the Zephyr 745 RTOS from version 2.0 ongoing. This implementation can be tested 746 with the overlay-6locan.conf on echo_server and echo_client 747 application. 749 12. Normative References 751 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 752 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 753 May 2017, . 755 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 756 "Transmission of IPv6 Packets over IEEE 802.15.4 757 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 758 . 760 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 761 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 762 DOI 10.17487/RFC4861, September 2007, 763 . 765 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 766 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 767 2006, . 769 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 770 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 771 February 2014, . 773 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 774 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 775 . 777 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 778 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 779 DOI 10.17487/RFC6282, September 2011, 780 . 782 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 783 Requirement Levels", BCP 14, RFC 2119, 784 DOI 10.17487/RFC2119, March 1997, 785 . 787 Author's Address 789 Alexander Wachter 790 Graz University of Technology 792 Email: alexander@wachter.cloud