RFC IPv6 over OWC July 2024
Choi, et al. Expires 6 January 2025 [Page]
Workgroup:
6lo
Published:
Intended Status:
Standards Track
Expires:
Authors:
Y. Choi, Ed.
ETRI
C-M. Kim
KETI
C. Gomez
Universitat Politecnica de Catalunya

Transmission of IPv6 Packets over Short-Range Optical Wireless Communications

Abstract

IEEE 802.15.7, "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both line-of-sight (LOS) and non-line-of-sight (NLOS) communications. This document describes how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.

Status of This Memo

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

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

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

This Internet-Draft will expire on 6 January 2025.

Table of Contents

1. Introduction

The rapid growth of the Internet of Things (IoT) has led to a significant increase in the number of wireless communication technologies utilized for real-time data collection and monitoring in various industrial domains, such as manufacturing, agriculture, healthcare, transportation, and so on. This trend highlights the importance of wireless communication in facilitating real-time data exchange and analysis, ultimately contributing to enhanced operational efficiency and decision-making processes across different industrial sectors.

Optical Wireless Communications (OWC) stands as one of the potential candidates for IoT wireless communication technologies, extensively applied across various industrial domains. The [IEEE802.15.7] standard outlines the procedures for establishing bidirectional communications between two OWC devices. Furthermore, IEEE 802.15.7 delineates a comprehensive OWC standard, encompassing features like Visible Light Communication (VLC), Short-Range Communication, Line-of-Sight (LOS) and Non-Line-of-Sight (NLOS) Support, High and Low Data Rates, Energy Efficiency, and Secure Communication.

OWC has potential to support IPv6-based IoT networking as one of the low-power wireless personal network (LoWPAN) technologies. OWC supports various network topologies, including peer-to-peer and star configurations. With IPv6 over OWC, it is possible to extend the network topology to include the mesh topology by using a route-over mechanism. However, IPv6 over OWC needs 6LoWPAN technologies [RFC4944] [RFC6282] [RFC6775] [RFC8505] because of the low bit rates, limited frame size and energy constraints of OWC.

2. 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 [RFC2119] [RFC8174] 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 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919], "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944], and "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC6775].

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.

3. Short-Range Optical Wireless Communications

Optical Wireless Communication (OWC) utilizes intensity modulation of optical sources, such as Light Emitting Diodes (LEDs) and Laser Diodes (LDs), to transmit data at speeds faster than what the human eye can perceive. OWC combines lighting and data communications, finding applications in various domains including area lighting, signboards, streetlights, vehicles, traffic signals, displays, LED panels, and digital signage.

IEEE802.15.7 describes the use of OWC for optical wireless personal area networks (OWPANs) and covers topics such as network topologies, addressing, collision avoidance, acknowledgment, performance quality indication, dimming support, visibility support, colored status indication, and color stabilization.

3.1. Network Topologies

The MAC layer of OWC provides three types of topologies: peer-to-peer, star and broadcast. In the star topology, the communication is established between devices and a single central controller, called the coordinator. In the peer-to-peer topology, one of the two devices in an association takes on the role of the coordinator. More complex topologies, such as the mesh topology, can be supported by using peer-to-peer at the higher layer with IPv6 over OWC.

3.2. Protocol Stack of OWC

IEEE 802.15.7 defines a protocol stack in terms of a number of layers and sublayers, depicted in Figure 1. The Physical Layer (PHY) in OWCs comprises the light transceiver and its associated low-level control mechanisms. It handles the transmission and reception of light signals, encoding and decoding data, and managing the physical characteristics of the communication channel. On top of the PHY, there is a Media Access Control (MAC) sublayer that facilitates access to the physical channel for various types of data transfers. The MAC sublayer controls how devices share the medium, manages access protocols, and ensures fair and efficient utilization of the optical wireless communication channel. The PHY and MAC sublayer form the data link layer in optical wireless communications, enabling the transmission and reception of data over the physical medium.

The upper layers, depicted in Figure 1, include the network layer responsible for network configuration, manipulation, and message routing, as well as the application layer which encompasses the intended functionality of the device. In order to access the MAC sublayer, a logical link control (LLC) layer can utilize the service-specific convergence sublayer (SSCS). The LLC layer provides a bridge between the upper layers and the MAC sublayer, facilitating the transfer of data and control information between the two layers. The upper layers, including the network layer and application layer, work in conjunction with the MAC sublayer and utilize the LLC layer and SSCS to enable efficient communication and functionality within the optical wireless communication system.

+----------------------------------------+ - - - - - - - - - -
|   Logical Link Control (LLC) Sublayer  |
+----------------------------------------+
|  Service-Specific Convergence Sublayer |   OWC Link Layer
+----------------------------------------+
|              MAC Sublayer              |
+----------------------------------------+ - - - - - - - - - -
|             Physical Layer             | OWC Physical Layer
+----------------------------------------+ - - - - - - - - - -
Figure 1: Protocol Stack of OWC

In order to send an IPv6 packet over OWC, the packet MUST be passed down to the LLC sublayer. For IPv6 addressing or address configuration, the LLC sublayer MUST provide related information, such as link-layer addresses, to its upper layer.

3.3. Addressing of OWC Devices

OWC devices have a unique 64-bit address. When a device associates with a coordinator node it is allowed to be allocated a short 16-bit address. Either address is allowed to be used for communication within the OWC data link network. Therefore, both of the 16-bit and 64-bit addresses can be used to generate an IPv6 Interface Identifier (IID).

3.4. MTU and data rates of OWC Link Layer

Table 1: MTU and Data Rates of IEEE 802.15.7
Type MTU Data Rates
PHY1 1,023 bytes 11.67 kbps ~ 266.6 kbps
PHY2 65,535 bytes 1.25 Mbps ~ 96 Mbps
PHY3 65,535 bytes 12 Mbps ~ 96 Mbps

Table 1 summarizes the maximum packet size is given by the OWC parameter "aMaxPHYFrame-Size", and the data rate that can be supported for each OWC PHY type, as specified in the IEEE 802.15.7.

4. Specification of IPv6 over OWC

OWC technology has requirements owing to low power consumption and allowed protocol overhead. 6LoWPAN standards [RFC4944][RFC6775] [RFC6282] provide useful functionality for reducing the overhead of IPv6 over OWC. This functionality consists of link-local IPv6 addresses and stateless IPv6 address autoconfiguration (see Sections 4.2 and 4.3), Neighbor Discovery (see Section 4.4), header compression (see Section 4.5) and and fragmentation (see Section 4.6).

4.1. Protocol Stack

Figure 2 illustrates the IPv6-over-OWC 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.

+----------------------------------------+
|         Upper-Layer Protocols          |
+----------------------------------------+
|                 IPv6                   |
+----------------------------------------+
|   Adaptation Layer for IPv6 over OWC   |
+----------------------------------------+
|          OWC Logical Link Layer        |
+----------------------------------------+
|           OWC Physical Layer           |
+----------------------------------------+
Figure 2: Protocol Stack for IPv6 over OWC

The Adaptation Layer for IPv6 over OWC supports Neighbor Discovery, stateless address autoconfiguration, header compression, and fragmentation and reassembly, based on 6LoWPAN. Note that 6LoWPAN header compression [RFC6282] does not define header compression for TCP. The latter can still be supported by IPv6 over OWC, albeit without the performance optimization of header compression.

4.2. Stateless Address Autoconfiguration

An OWC device performs stateless address autoconfiguration as per [RFC4862]. A 64-bit IID for an OWC interface is formed by utilizing the 16-bit or 64-bit address (see Section 3.3). In the viewpoint of address configuration, such an IID should guarantee a stable IPv6 address during the course of a single connection because each data link connection is uniquely identified by OWC Data Link Layer.

Following the guidance of [RFC7136], IIDs of all unicast addresses for OWC devices are 64 bits long and constructed by using the generation algorithm of random identifiers (RIDs) that are stable [RFC7217].

The RID is an output created by the F() algorithm with input parameters. One of the parameters is Net_Iface, and the OWC 16-bit Link-Layer Address MUST be a source of the Net_Iface parameter. The 16-bit address can easily be targeted by attacks from a third party (e.g., address scanning). The F() algorithm with SHA-256 can provide secured and stable IIDs for OWC devices. In addition, an optional parameter, Network_ID, is used to increase the randomness of the generated IID with the OWC Link-Layer Address. The secret key SHOULD be at least 128 bits. It MUST be initialized to a pseudorandom number [RFC4086].

4.4. Neighbor Discovery

Neighbor Discovery Optimization for 6LoWPANs [RFC6775][RFC8505] describes the Neighbor Discovery approach in several 6LoWPAN topologies, such as mesh topology. IPv6 over OWC supports mesh topologies with route-over.

  • When an OWC 6LN is directly connected to a 6LBR, the 6LN MUST register its address with the 6LBR by sending Neighbor Solicitation (NS) with the Extended Address Registration Option (EARO) [RFC8505]. When the 6LN and 6LBR are linked to each other, 6LBR assigns an address to the 6LN. In this process, Duplicate Address Detection (DAD) [RFC6775]. is not required.
  • When two or more multi-hop topology by OWC 6LNs are connected to the 6LBR, the 6LBR performs DAD for the acquired link-local address of the 6LNs. In this topology, 6LNs that have two or more links with neighbor nodes may act as routers.
  • For receiving RSs and RAs, the OWC 6LNs MUST follow Sections 5.3 and 5.4 of [RFC6775].
  • When an OWC device is a 6LR or 6LBR, the OWC device MUST follow Sections 6 and 7 of [RFC6775].

4.5. Header Compression

4.5.1. Traditional 6LoWPAN header compression

Header compression as defined in [RFC6282], which specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, is REQUIRED in this document as the basis for IPv6 header compression on top of OWC. All headers MUST be compressed according to the encoding formats described in [RFC6282].

Therefore, IPv6 header compression in [RFC6282] MUST be implemented. Further, implementations MUST also support Generic Header Compression (GHC) as described in [RFC7400].

If a 16-bit address is required as a short address, it MUST be formed by the 16-bit OWC Link Layer Address as shown in Figure 4.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit OWC Link Layer Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: OWC Short Address Format

4.5.2. SCHC header compression

In addition, OWC devices MAY utilize the header compression mechanism offered by Static Context Header Compression and fragmentation (SCHC) [I-D.ietf-schc-architecture]. For instance, SCHC may be used to compress IPv6 headers, IPv6/UDP headers, IPv6/UDP/CoAP (if CoAP is used), etc. [I-D.ietf-schc-architecture].

In the star topology, in order to signal that a node supports SCHC for header compression, the node uses the 6LoWPAN Capability Indication Option (6CIO), with a new 6LoWPAN Capability Bit called the "S" bit, defined by the present specification. The "S" bit is the last bit (47th bit) of the "6LoWPAN Capability Bits" subregistry (see Figure 5).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length = 1  |   Reserved    |X|A|D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                          |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: New Capability Bit in the 6CIO

New option fields:
S:
1-bit flag. Set to indicate that the node sending the 6CIO option supports SCHC for header compression.

Typically, the 6CIO (with the "S" bit set) will only be sent in 6LoWPAN-ND Router Solicitation (RS) packets. The resulting 6LoWPAN-ND Router Advertisement (RA) can then already make use of SCHC and thus indicate SCHC capability implicitly.

In a multihop topology, SCHC header compression can only be used as long as the whole 6LoWPAN network is administratively required to support SCHC-compressed packet transmission over a multihop network. In that case, all network nodes MUST support at least one of the route-over modes defined in [I-D.ietf-6lo-schc-15dot4], i.e., Straightforward Route-Over (SRO), Tunneled, RPL-based Route-Over (TRO) or Pointer-based Route-Over (PRO), and all network nodes MUST use the same route-over mode at a given time.

In order to transmit a SCHC-compressed IPv6 packet over OWC, the frame format to be used depends on the network topology (i.e., star vs multihop) and, for multihop topologies, on the route-over mode used. The frame format SHALL be the corresponding one defined in Sections 4.1 to 4.3 of [I-D.ietf-6lo-schc-15dot4], where "IEEE 802.15.4 frame payload" needs to be replaced by "IEEE 802.15.7 frame payload" in the case of IPv6 over OWC.

4.6. Fragmentation and Reassembly Considerations

For PHY1 of OWC, IPv6 over OWC MUST use [RFC4944] Fragmentation and Reassembly (FAR). The MTU of OWC PHY1 is smaller than the MTU of IPv6 Packet (1280 bytes). However, because the MTU of OWC PHY2 and PHY3 are bigger than MTU of IPv6 Packet, IPv6 over OWC MUST NOT use [RFC4944] FAR at the adaptation layer for the payloads as discussed in Section 3.4.

Even though OWC devices have larger MTUs (i.e., PHY2 and PHY3) than 1280 octets, use of a 1280-octet MTU is RECOMMENDED in order to avoid need for Path MTU discovery procedures [RFC7668].

4.7. Unicast and Multicast Address Mapping

The address resolution procedure for mapping IPv6 non-multicast addresses into OWC Link-Layer Addresses follows the general description in Sections 4.6.1 and 7.2 of [RFC4861], unless otherwise specified.

The Source/Target Link-Layer Address option has the following form when the addresses are 16-bit OWC Link Layer Addresses.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length=1    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-     Padding (all zeros)     -+
|                               |
++-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+
| OWC 16-bit Link Layer Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Unicast Address Mapping

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 bits. The value of this field is 1 for 16-bit OWC Link Layer addresse.

The OWC Link Layer does not support multicast. Therefore, packets are always transmitted unicast between two OWC devices. Even in the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot multicast to all the connected 6LNs. If the 6LBR needs to send a multicast packet to all its 6LNs, it has to replicate the packet and unicast it on each link. However, this is not energy-efficient; the central node, which is battery-powered, must take particular care of power consumption. To further conserve power, the 6LBR MUST keep track of multicast listeners at OWC link-level granularity (not at subnet granularity), and it MUST NOT forward multicast packets to 6LNs that have not registered as listeners for multicast groups the packets belong to. In the opposite direction, a 6LN always has to send packets to or through the 6LBR. Hence, when a 6LN needs to transmit an IPv6 multicast packet, the 6LN will unicast the corresponding OWC packet to the 6LBR.

5. Internet Connectivity Scenarios

5.1. OWC Device Network Connected to the Internet

Figure 7 illustrates an example of an OWC device network connected to the Internet. Another OWC devices may run as 6LNs and 6LRs, and they communicate with the 6LBR, as long as both are within each other's range.

      OWC
      Link
6LR -------- 6LBR --( Internet )-- Corresponding Node
 .             .
 .<--Subnet--> .
 .   to the    .
 .  Internet   .
Figure 7: OWC Device Network Connected to the Internet

The 6LBR is acting as a router and forwarding packets between 6LNs and the Internet. Also, the 6LBR MUST ensure address collisions do not occur because the 6LNs are connected to the 6LBR like a start topology, so the 6LBR checks whether or not IPv6 addresses are duplicates, since 6LNs need to register their addresses with the 6LBR.

5.2. OWC Device Ad-hoc Network

In some scenarios, the OWC device network may permanently be a simple isolated ad-hoc network as shown in Figure 8.

                           6LN                        6LN
                            |                          |
                 OWC link ->|               OWC link ->|
                            |                          |
6LN ---------------------- 6LR ---------------------- 6LR
 .         OWC link                    OWC link        |
 .                                                     |
 .                                          OWC link ->|
 .                                                    6LN
 .                                                     .
 . < - - - - - - - - - -  Subnet - - - - - - - - - - > .
Figure 8: Isolated OWC Device Network

In multihop (i.e., more complex) topologies, DAD requires the extensions for multihop networks, such as the ones in [RFC6775].

6. IANA Considerations

IANA is requested to make the following addition to the "6LoWPAN Capability Bits" subregistry, as follows:

+------+---------------------------+------------+
| Bit  | Description               | Reference  |
+------+---------------------------+------------+
|  47  | SCHC Support (S bit)      | RFC This   |
+------+---------------------------+------------+
Figure 9: New 6LoWPAN Capability Bit (S bit)

7. Security Considerations

[TBD]

8. References

[I-D.ietf-6lo-schc-15dot4]
Gomez, C. and A. Minaburo, "Transmission of SCHC-compressed packets over IEEE 802.15.4 networks", Work in Progress, Internet-Draft, draft-ietf-6lo-schc-15dot4-06, , <https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-6lo-schc-15dot4/>.
[I-D.ietf-schc-architecture]
Pelov, A., Thubert, P., and A. Minaburo, "Static Context Header Compression (SCHC) Architecture", Work in Progress, Internet-Draft, draft-ietf-schc-architecture-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-schc-architecture-02>.
[IEEE802.15.7]
IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.7: Short-Range Optical Wireless Communications", IEEE Std 8802.15.7-2018, DOI 10.1109/IEEESTD.2019.8697198, , <https://ieeexplore.ieee.org/document/8697198>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4086]
Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, , <https://www.rfc-editor.org/info/rfc4086>.
[RFC4861]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, , <https://www.rfc-editor.org/info/rfc4862>.
[RFC4919]
Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, , <https://www.rfc-editor.org/info/rfc4919>.
[RFC4944]
Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, , <https://www.rfc-editor.org/info/rfc4944>.
[RFC6282]
Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, , <https://www.rfc-editor.org/info/rfc6282>.
[RFC6775]
Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, , <https://www.rfc-editor.org/info/rfc6775>.
[RFC7136]
Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, , <https://www.rfc-editor.org/info/rfc7136>.
[RFC7217]
Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, , <https://www.rfc-editor.org/info/rfc7217>.
[RFC7400]
Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, , <https://www.rfc-editor.org/info/rfc7400>.
[RFC7668]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, , <https://www.rfc-editor.org/info/rfc7668>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8201]
McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, , <https://www.rfc-editor.org/info/rfc8201>.
[RFC8505]
Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, , <https://www.rfc-editor.org/info/rfc8505>.
[RFC8724]
Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, , <https://www.rfc-editor.org/info/rfc8724>.

Acknowledgements

We are grateful to the members of the IETF 6lo Working Group.

Authors' Addresses

Younghwan Choi (editor)
Electronics and Telecommunications Research Institute
218 Gajeongno, Yuseung-gu
Daejeon
34129
South Korea
Cheol-min Kim
Korea Electronics Technology Institute
25, Saenari-ro, Bundang-Gu, Seongnam-Si
Gyeonggi-do
13509
South Korea
Carles Gomez
Universitat Politecnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain