]> Graz University of Technology

alexander@wachter.cloud

Electronics and Telecommunications Research Institute

218 Gajeongno, Yuseong-gu Daejeon 34129 South Korea +82 42 860 6514 pjs@etri.re.kr

int 6lo Controller Area Network CAN ISO 11898 ISO-TP 6LowPAN IPv6 Adaptation Layer IoT Internet of Things Controller Area Network (CAN) is a fieldbus initially designed for automotive applications. It has since been adopted for use in various industrial applications, such as CANopen and building automation systems. CAN operates as a multi-master bus with frame identifiers of 11 bits or 29 bits. The CAN standard, defined in the ISO 11898 series, specifies both the physical and data-link layers. This document describes how to transfer IPv6 packets over CAN using ISO-TP, a dedicated addressing scheme for CAN nodes, and IP header compression (IPHC).

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 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.

Applicability CAN is used in domains other than the automotive one it was designed for. Two properties recur in those domains: a bus that is already installed and certified as part of the equipment, and devices that are increasingly expected to be reachable from an IP network for monitoring, configuration or software update. Elevators are an example. An elevator installation uses CAN to connect the controller with the car, the door operator and the landing stations. The bus is specified as part of the installation and cannot be replaced without re-certifying it, while the same installation is expected to report its state to a building management system or to a remote maintenance service. Such connectivity is commonly provided by a gateway that translates a vendor-specific CAN protocol into an IP protocol, and that translation has to be provided for each combination of equipment and management system. Running IPv6 on the existing CAN bus removes that per-combination translation. The controller, the car and the landing stations become IPv6 nodes that a management system addresses in the same way as any other node, and the Ethernet Border Translator (see ) is the only element that has to be adapted to the building network. The same reasoning applies to other installations that use CAN for their internal communication, such as CANopen machinery and building automation. 6LoCAN assumes a single bus segment with a modest number of nodes that are powered from the installation rather than battery operated, and traffic that consists mostly of small messages. It is not intended for installations that need the throughput of Ethernet, nor for battery-operated nodes that need the duty-cycling support of and .

Conventions and 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 when, and only when, they appear in all capitals, as shown here. This specification requires readers to be familiar with all the terms and concepts that are discussed in "IPv6 Stateless Address Autoconfiguration" , "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" , "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" , "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" , and "SCHC: Generic Framework for Static Context Header Compression and Fragmentation" .

6LoWPAN Node (6LN):

A 6LoWPAN node is any host or router participating in a LoWPAN. This term is used when referring to situations in which either a host or router can play the role described.

6LoWPAN Router (6LR):

An intermediate router in the LoWPAN that is able to send and receive Router Advertisements (RAs) and Router Solicitations (RSs), as well as forward and route IPv6 packets. 6LoWPAN Routers are present only in route-over topologies.

6LoWPAN Border Router (6LBR):

A border router located at the junction of separate 6LoWPAN networks or between a 6LoWPAN network and another IP network. There may be one or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the responsible authority for IPv6 prefix propagation for the 6LoWPAN network it is serving. An isolated LoWPAN also contains a 6LBR in the network that provides the prefix(es) for the isolated network.

Duplicate Address Detection (DAD):

A mechanism used in IPv6 networks to ensure that no two devices share the same address, preventing address conflicts.

Static Context Header Compression and fragmentation (SCHC):

A header compression and fragmentation framework defined in . It relies on a context that is known to both endpoints before a packet is sent, and elides the header fields whose values can be derived from that context.

Controller Area Network Overview This section provides a brief overview of Controller Area Network (CAN), as specified in and . CAN has two wires, CAN High and CAN Low. When a dominant (0) bit is transmitted, CAN High is driven to a higher voltage than CAN Low, so that the differential voltage between the two wires is nominally 2V. Both wires are at approximately the same level when a recessive (1) bit is transmitted, so that the differential voltage is nominally 0V. specifies the voltage levels. 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.

ISO-TP Overview This section provides information about the use of ISO-TP () 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. This applies to the transfer of IPv6 packets only; link-layer duplicate address detection uses the classical CAN frame format (see ).

Specification of IPv6 over CAN CAN technologies have requirements owing to low power consumption and allowed protocol overhead. 6LoWPAN standards provide useful functionality for reducing the overhead of IPv6 over CAN. This functionality consists of link-local IPv6 addresses and stateless IPv6 address autoconfiguration (see Sections and ), Neighbor Discovery (see ), header compression (see ) and fragmentation (see ).

Protocol Stack illustrates the IPv6-over-CAN protocol stack. Upper-layer protocols can be transport-layer protocols (e.g., TCP and UDP), application-layer protocols, and other protocols capable of running on top of IPv6.

The Adaptation Layer for IPv6 over CAN supports Neighbor Discovery, stateless address autoconfiguration, header compression, and fragmentation and reassembly, based on 6LoWPAN. Note that 6LoWPAN header compression does not define header compression for TCP.

CAN Frame Identifiers 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. The ranges listed in apply to node addresses, that is, to the source address of every frame and to the destination address of unicast frames (see ). They do not apply to the destination address of multicast frames: that field carries the low-order 14 bits of the multicast group as specified in , and the multicast bit distinguishes such a value from a node address. 6LoCAN does not use the 11-bit standard identifiers. They may be used for other purposes. Address Description 0x3DFF - 0x3FFF Reserved 0x3DFE LLDAD 0x3DF1 - 0x3DFD Reserved 0x3DF0 Ethernet Translator 0x0100 - 0x3DEF Node addresses 0x0000 - 0x00FF Reserved

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:

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

Unicast Frame Identifier 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 . Every node MUST be able to receive all frames targeting its address as the destination address.

Multicast Frame Identifier 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.

Node 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.

Link-Layer Duplicate Address Detection This section provides information about how to perform link-layer duplicate address detection (LLDAD). LLDAD is introduced to prevent collisions of CAN identifiers and makes it possible to use random address assignment with only 14 bits of address space. To perform an LLDAD, a LLDAD-request is sent. If there is no DAD-response sent back, the DAD is considered successful. The node MUST wait for a response for at least 100ms. LLDAD-requests are remote transmission request (RTR) frames with the desired address as the destination and 14 bits entropy as the source address. The entropy prevents identifier collisions when nodes are trying to get the same address at the same time. LLDAD frames MUST use the classical CAN frame format. The CAN FD frame format does not support remote frames: the RTR bit position is replaced by the Remote Request Substitution (RRS) bit, which is always transmitted as dominant (). Nodes that exchange data in the CAN FD frame format therefore send and receive LLDAD-requests and DAD-responses in the classical CAN frame format. Both frame formats may coexist on the same bus segment. Consequently, a 6LoCAN node MUST support the classical CAN frame format even when all of its data traffic uses the CAN FD frame format. DAD-responses are data-frames sent to the LLDAD address (0x3DFE) with the responder's address as the source address. Both LLDAD-request and DAD-response have a data length of zero. The node MUST be configured to receive RTR frames with the desired address as the destination address before the LLDAD-request is sent and frames with the LLDAD address as long as the LLDAD is in progress. This prevents from assigning the same address to more than one node when sending the LLDAD-request at the same time. The ability to receive RTR frames with the desired address as the destination address MUST be kept as long as the node uses the address. The response to LLDAD-requests that matches the node address MUST be sent before the requesting node stops waiting for the response, which is 100ms. shows a DAD Fail example where node A performs a LLDAD-request on address 0x3055 where this address is already in use by node B.

| | | |<-LLDAD-response-| LLDAD-request identifier: This frame is a Remote Transmission Request (RTR) 0|0 1|1 2| 0|1 4|5 8| +-+--------------+--------------+ |0|11000001010101| entropy | +-+--------------+--------------+ DAD-response identifier: 0|0 1|1 2| 0|1 4|5 8| +-+--------------+--------------+ |0|11110111111110|11000001010101| +-+--------------+--------------+ ]]>

Stateless Address Autoconfiguration This section defines how to obtain an IPv6 Interface Identifier. The Interface Identifier for link-local addresses SHOULD be formed by taking the node address and zero filling it to the left. The resulting value is an IID in the sense of and carries no embedded meaning beyond the node address. For example, an address of hexadecimal value 0x3AAF results in the following IID:

Deriving the IID from the node address allows IPHC to elide the IID of a link-local address, because the receiver can reconstruct it from the CAN frame identifier. Any other IID has to be carried in-line, which costs 8 octets in every frame that carries an IPv6 header. On a link whose frames carry at most 64 octets of payload, this is the difference between a usefully compressed header and an uncompressed one. recommends that stable IIDs be generated with the method of rather than from a link-layer address. The link-local IID defined above is a deliberate deviation from that recommendation, made for the header compression reason given above; its privacy properties are discussed in . For addresses other than link-local addresses, a 6LoCAN node SHOULD generate IIDs as described in . Such IIDs cannot be elided by IPHC and are carried in-line.

IPv6 Link-Local Address The IPv6 link-local address for a 6LoCAN interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.

Neighbor Discovery A 6LoCAN bus segment is a single link. Every node attached to the segment can reach every other node of that segment directly, and nodes do not forward packets between each other within a segment. Neighbor Discovery for IPv6 is used for address resolution and for neighbor unreachability detection. The Source/Target Link-Layer Address option carries the 14-bit node address in the form specified in . The Neighbor Discovery optimizations for 6LoWPANs address route-over, multi-hop topologies in which multicast is expensive or unreliable. Because a 6LoCAN segment is a single link and CAN provides a multicast mechanism (see ), these optimizations are not required within a segment. Connectivity between a 6LoCAN segment and other links is provided by the Ethernet Border Translator (see ) rather than by a 6LBR.

Header Compression

Traditional 6LoWPAN Header Compression TBD

SCHC Header Compression Refer to .

Maximum Transmission Unit IPv6 requires every link to have an MTU of 1280 octets or greater . The subset of ISO-TP used in this document (see ) carries up to 4095 octets per packet and therefore satisfies this requirement. The MTU of a 6LoCAN bus segment MUST be at least 1280 octets and MUST NOT exceed 4095 octets. Implementations SHOULD use an MTU of 1280 octets. All nodes attached to the same bus segment MUST use the same MTU; 6LoCAN provides no mechanism to negotiate the MTU on a per-node basis. A larger MTU increases the reassembly buffer that every receiving node has to provide and the number of CAN frames that a single IPv6 packet occupies. Because ISO-TP transfers are interleaved with other bus traffic at frame granularity, a long transfer does not block frames of higher priority, but it does increase the latency of traffic whose identifiers have a lower priority than the transfer. An MTU larger than 1280 octets SHOULD therefore be used only where the resulting bus occupancy is acceptable for the application.

Fragmentation and Reassembly Considerations 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 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.

IPv6 Address Mapping

Unicast Address Mapping The address resolution procedure for mapping IPv6 non-multicast addresses into CAN Data link layer Addresses (Node addresses) follows the general description in Sections 4.6.1 and 7.2 of , unless otherwise specified. The Source/Target Link-Layer Address option has the following form when the addresses are 14-bit CAN Data Link Layer Addresses.

Option fields:

Type:

1: This is for the Source Link-Layer Address. 2: This is for the Target Link-Layer Address.

Length:

This is the length of this option (including the Type and Length fields) in units of 8 octets. The value of this field is 1 for 14-bit CAN Data Link Layer addresses.

Rsv:

Reserved. 2 bits. These bits MUST be set to zero by the sender and MUST be ignored by the receiver.

CAN Data Link-Layer Address:

The 14-bit node address of the sender (Source Link-Layer Address) or of the target (Target Link-Layer Address).

Multicast Address Mapping CAN has no link-layer multicast address. An IPv6 multicast address is therefore mapped directly onto a frame identifier: the multicast bit is set and the destination field carries the low-order 14 bits of the multicast group, as specified in . No link-layer address resolution is performed for a multicast destination, and the Source/Target Link-Layer Address option is not used for one. Because the CAN data link layer does not provide multicast, ISO-TP is used for multicast frames without its flow control mechanism; see and .

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.

The in-line IPv6 header fields are the fields that LOWPAN_IPHC could not elide: traffic class and flow label (4 octets), next header (1 octet), hop limit (1 octet), source address (16 octets) and destination address (16 octets). This amounts to 38 octets when none of them can be elided, and to 0 octets when all of them can. 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.

Ethernet Border Translator This section specifies how 6LoCAN packets are translated to and from 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 , ). 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 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.

Internet Connectivity Scenarios This section shows an example of a 6LoCAN segment connected to an Ethernet network and examples of the address translations specified in . shows an example setup of a 6LoCAN segment connected to an Ethernet network. shows a translation from Ethernet MAC to CAN identifier. The source (src) MAC address is carried in-line in the CAN frame data. The 34-bit MAC address prefix for this example is 02:00:5E:10 followed by two zero bits, written as 02:00:5E:10:00/34.

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

shows a translation CAN identifier to Ethernet MAC. The destination (dest) MAC address is carried inline in the CAN frame data. The 34-bit MAC address prefix for this example is 02:00:5E:10 followed by two zero bits, written as 02:00:5E:10:00/34.

|ETH|Border |CAN|------+--------+---- ... | | | | |Translator| | +--------+---+ +---+----------+---+ ]]>

IANA Considerations The IANA considerations for this document have not yet been determined. A future revision will specify the registry actions required by this document, or state that this document has no IANA actions.

Security Considerations This document doesn't provide any security mechanisms. Traffic on the bus can be intercepted, spoofed, or destroyed. For confidentiality and integrity, mechanisms like TLS or IPsec need to be applied. The link-local IID defined in is derived from the node address and therefore exposes that address in every link-local IPv6 address of the node. Within a bus segment this discloses nothing new, because the node address appears in the CAN frame identifier of every frame the node sends or receives. It would become a concern if the node address were also used to form addresses that are routable beyond the segment: such an address would remain stable for as long as the node keeps its node address and would allow the node to be tracked across networks, which is what and are intended to prevent. For this reason the node address is used only for link-local IIDs. A 14-bit node address space holds 16384 values and can be scanned exhaustively in a short time. The size of the address space therefore provides no protection against discovery of the nodes present on a bus segment.

This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK] This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK] This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK] The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK] The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly. This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses). This document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network. This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. UPC Consultant A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for the Internet community. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Graz University of Technology 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). ISO ISO ISO

Acknowledgements This document is based on , an earlier Internet-Draft authored by Alexander Wachter.