Transmission of IPv6 Packets over Short-Range Optical Wireless Communications
draft-ietf-6lo-owc-05
| Document | Type | Active Internet-Draft (6lo WG) | |
|---|---|---|---|
| Authors | Younghwan Choi , Cheol-min Kim , Carles Gomez | ||
| Last updated | 2025-10-19 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestone |
|
||
| Document shepherd | Shwetha Bhandari | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | shwetha.bhandari@gmail.com |
draft-ietf-6lo-owc-05
6lo Y. Choi, Ed.
Internet-Draft ETRI
Intended status: Standards Track C-M. Kim
Expires: 24 April 2026 KETI
C. Gomez
Universitat Politecnica de Catalunya
21 October 2025
Transmission of IPv6 Packets over Short-Range Optical Wireless
Communications
draft-ietf-6lo-owc-05
Abstract
[IEEE802.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. However, ambient light interference from natural
sunlight or artificial lighting sources can impact signal
reliability. To mitigate this, advanced modulation techniques,
optical filtering, and adaptive power control can be employed. 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 24 April 2026.
Choi, et al. Expires 24 April 2026 [Page 1]
RFC IPv6 over OWC October 2025
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Short-Range Optical Wireless Communications . . . . . . . . . 5
3.1. Network Topologies . . . . . . . . . . . . . . . . . . . 5
3.2. Protocol Stack of OWC . . . . . . . . . . . . . . . . . . 5
3.3. Addressing of OWC Devices . . . . . . . . . . . . . . . . 6
3.4. MTU and data rates of OWC Link Layer . . . . . . . . . . 7
4. Specification of IPv6 over OWC . . . . . . . . . . . . . . . 7
4.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 7
4.2. Stateless Address Autoconfiguration . . . . . . . . . . . 8
4.3. IPv6 Link-Local Address . . . . . . . . . . . . . . . . . 8
4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 9
4.5. Header Compression . . . . . . . . . . . . . . . . . . . 9
4.5.1. Traditional 6LoWPAN header compression . . . . . . . 9
4.5.2. SCHC header compression . . . . . . . . . . . . . . . 10
4.6. Fragmentation and Reassembly Considerations . . . . . . . 11
4.7. Unicast and Multicast Address Mapping . . . . . . . . . . 11
5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 13
5.1. OWC Device Network Connected to the Internet . . . . . . 13
5.2. OWC Device Multi-hop Network . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Annex A. Example Use of Combined 6LoWPAN HC and SCHC . . . . . . 17
A.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18
A.2 Compression Selection Strategy . . . . . . . . . . . . . . 18
A.3 Example Scenarios . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Choi, et al. Expires 24 April 2026 [Page 2]
RFC IPv6 over OWC October 2025
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 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. In
addition, the standard has evolved through subsequent related
developments to address emerging application requirements:
* [IEEE802.15.7a] introduces Optical Camera Communications (OCC),
utilizing image sensors for data reception, making OWC applicable
to smart city applications and enhanced vehicular communication.
* [IEEE802.15.13-2023] was developed for industrial IoT and includes
new PHYs with pulse modulation (OOK/FDE) and adaptive OFDM for
factory automation and real-time industrial networking.
* [IEEE802.11bb-2023] extends Wi-Fi technology to optical
communication, leveraging the existing 802.11 MAC and PHY layers.
This enables seamless integration of OWC into mainstream wireless
networks, opening new possibilities for high-speed data
transmission in indoor environments.
While IEEE 802.15.7 and its related amendments define the physical
and MAC layers for Optical Wireless Communication (OWC), the
documents do not specify how IPv6 packets are transmitted over such
links. Therefore, this document defines the adaptation of IPv6 over
OWC to enable IP-based interoperability across OWC and other low-
power wireless technologies.
OWC is immune to Radio Frequency (RF) interference, making it highly
suitable for environments such as hospitals, airplanes, and
industrial facilities, where RF interference is a concern.
Additionally, OWC can leverage existing visible light infrastructure,
Choi, et al. Expires 24 April 2026 [Page 3]
RFC IPv6 over OWC October 2025
reducing deployment costs for smart lighting and IoT applications.
OWC also provides energy-efficient operation. Nevertheless, OWC
performance is affected in Non-Line-of-Sight (NLoS) links, and by
interference produced by ambient light sources.
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. Implementing
header compression (e.g., 6LoWPAN or SCHC) significantly reduces
packet size, lowering transmission power requirements and extending
battery life for IoT devices. This makes OWC an alternative for low-
power wireless communication in energy-constrained environments.
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 Stateless Address
Autoconfiguration" [RFC2462], "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], and "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation" [RFC8724].
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.
Choi, et al. Expires 24 April 2026 [Page 4]
RFC IPv6 over OWC October 2025
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.
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
Choi, et al. Expires 24 April 2026 [Page 5]
RFC IPv6 over OWC October 2025
optical wireless communication channel. The PHY and MAC sublayer
form the data link layer in optical wireless communication, 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).
Choi, et al. Expires 24 April 2026 [Page 6]
RFC IPv6 over OWC October 2025
3.4. MTU and data rates of OWC Link Layer
+===================+==============+=========================+
| Type | MTU | Data Rates |
+===================+==============+=========================+
| PHY Type 1 (PHY1) | 1,023 bytes | 11.67 kbps ~ 266.6 kbps |
+-------------------+--------------+-------------------------+
| PHY Type 2 (PHY2) | 65,535 bytes | 1.25 Mbps ~ 96 Mbps |
+-------------------+--------------+-------------------------+
| PHY Type 3 (PHY3) | 65,535 bytes | 12 Mbps ~ 96 Mbps |
+-------------------+--------------+-------------------------+
Table 1: MTU and Data Rates of IEEE 802.15.7
Table 1 summarizes the maximum packet size is given by the OWC
parameter "aMaxPHYFrameSize", 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 |
+----------------------------------------+
Choi, et al. Expires 24 April 2026 [Page 7]
RFC IPv6 over OWC October 2025
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 Random Identifier (RID) is derived using the F() algorithm
defined in [RFC7217]. One of the input parameters to F() is
Net_Iface, which MAY be derived from the 16-bit or 64-bit OWC Link-
Layer Address. However, because short (16-bit) addresses are easily
predictable and can be subject to address-scanning attacks,
implementations SHOULD apply the randomized identifier generation
scheme of [RFC7217] to ensure IID stability and privacy. The F()
algorithm SHALL use SHA-256 as the hash function. An optional
Network_ID parameter MAY be included to increase randomness in IID
generation. The secret key MUST be at least 128 bits long and SHOULD
be initialized with a cryptographically strong pseudorandom value as
recommended in [RFC4086].
4.3. IPv6 Link-Local Address
The IPv6 Link-Local Address for an OWC device is formed by appending
the IID to the prefix fe80::/64, as depicted in Figure 3.
Choi, et al. Expires 24 April 2026 [Page 8]
RFC IPv6 over OWC October 2025
0 0 0 1
0 1 6 2
0 0 4 7
+----------+------------------+----------------------------+
|1111111010| zeros | Interface Identifier |
+----------+------------------+----------------------------+
. .
. <- - - - - - - - - - - 128 bits - - - - - - - - - - - -> .
. .
Figure 3: IPv6 Link-Local Address in OWC
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 registers
its address with the 6LBR by sending a Neighbor Solicitation (NS)
message including the Extended Address Registration Option (EARO)
[RFC8505]. In this single-hop case, Duplicate Address Detection
(DAD)[RFC6775] is not required, since the 6LBR manages address
registrations for its attached nodes.
* For multi-hop topologies, the 6LBR MUST perform DAD on registered
addresses to ensure address uniqueness across the entire OWC
network. In such networks, intermediate 6LNs that connect to
multiple neighbors MAY act as 6LoWPAN Routers (6LRs) to forward
Neighbor Discovery messages as specified in [RFC6775].
* When 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].
Choi, et al. Expires 24 April 2026 [Page 9]
RFC IPv6 over OWC October 2025
Therefore, IPv6 header compression in [RFC6282] MUST be implemented.
Further, implementations MAY 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
The 6LoWPAN Capability Indication Option (6CIO) is defined in
[RFC6775]. This document introduces a new capability flag, the ‘S’
bit, indicating support for SCHC header compression. In addition,
Static Context Header Compression and fragmentation (SCHC)[RFC8724]
is optionally used in OWC networks to reduce overhead. A signaling
mechanism SHOULD be implemented to indicate whether a node supports
SCHC compression. For instance, SCHC MAY be used to compress IPv6
headers, IPv6/UDP headers, IPv6/UDP/CoAP (if CoAP is used), etc.
[RFC8724].
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. This 'S' bit is intended to indicate generic SCHC
functionality, so that it is applicableit emulates beyond OWC
networks. Future standardization efforts MAY define a generic
specification for the 'S' bit that extends to other link-layer
technologies. The "S" bit is the last bit (47th bit) of the "6LoWPAN
Capability Bits" registry (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 6LoWPAN Capability Bit in the 6CIO
Choi, et al. Expires 24 April 2026 [Page 10]
RFC IPv6 over OWC October 2025
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.
Choi, et al. Expires 24 April 2026 [Page 11]
RFC IPv6 over OWC October 2025
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.
IEEE 802.15.7 does not natively support link-layer multicast
transmission. Therefore, IPv6 packets over OWC are normally
delivered as unicasts between two OWC devices. When a 6LBR is
connected to multiple 6LNs, it MAY emulate multicast delivery by
performing link-layer broadcast or by replicating packets as multiple
unicasts, while considering the resulting energy impact on
constrained nodes.
To reduce unnecessary transmissions, the 6LBR SHOULD maintains a
record of multicast listeners at the OWC link-layer granularity
(rather than the subnet level) and MUST NOT forward multicast packets
to 6LNs that have not registered as listeners for the relevant
groups.
In the reverse direction, a 6LN MUST send IPv6 multicast packets as
unicasts to the 6LBR, which then distributes them according to its
multicast listener table.
Choi, et al. Expires 24 April 2026 [Page 12]
RFC IPv6 over OWC October 2025
5. Internet Connectivity Scenarios
The scenarios in this section provide useful context for
understanding OWC device network configurations. To further clarify,
OWC can operate in two primary configurations.
* Single-hop networks: Suitable for small-scale IoT applications
such as small-scale smart home automation, where OWC-enabled
devices communicate directly.
* Multi-hop networks: Suitable Where OWC devices relay data across
multiple hops to extend the network range (e.g., for industrial
IoT deployments). Additionally, interoperability with other 6lo
wireless technologies can be considered. In hybrid networks, IPv6
over OWC can coexist with these technologies by utilizing IPv6
routing mechanisms, allowing seamless integration with existing
infrastructure.
5.1. OWC Device Network Connected to the Internet
Figure 7 illustrates an example of an OWC device network connected to
the Internet. Each OWC device, such as a 6LN, 6LR, or 6LBR, is
considered an OWC device, and they communicate with one another as
long as they are within each other's range.
6LN
|
OWC link → |
↓ |
6LR ------- 6LBR -- (( Internet )) -- Corresponding Node
. .
.<-Subnet--> .
. to the .
. Internet .
Figure 7: Example of 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 ensures 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.
Choi, et al. Expires 24 April 2026 [Page 13]
RFC IPv6 over OWC October 2025
5.2. OWC Device Multi-hop Network
In some scenarios, the OWC device network MAY operate as a simple,
isolated ad-hoc network, as illustrated in Figure 8. Two groups of
6LNs are interconnected in a star topology, with each group connected
to a 6LR.
6LN 6LN
| |
OWC link → | OWC link → |
↓ | ↓ |
6LN -------- 6LR -------------- 6LR ------- 6LN
. | ↑ .
. | ← OWC link .
. | .
. 6LN .
. .
. < - - - - - - - Subnet - - - - - - - - > .
Figure 8: Example of isolated OWC Device Multi-hop 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" registry, as follows:
+----------------+---------------------------+------------+
| Bit | Description | Reference |
+----------------+---------------------------+------------+
| 47 (suggested) | SCHC Support (S bit) | RFC This |
+----------------+---------------------------+------------+
Figure 9: New 6LoWPAN Capability Bit (S bit)
7. Security Considerations
Security mechanisms for IPv6 over OWC MUST address confidentiality,
integrity, and replay protection. Future work may consider optical-
layer encryption and physical-layer key establishment.
8. References
8.1. Normative References
Choi, et al. Expires 24 April 2026 [Page 14]
RFC IPv6 over OWC October 2025
[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-11,
14 October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-6lo-schc-15dot4-11>.
[IEEE802.15.7]
IEEE, "IEEE Standard for Local and metropolitan area
networks--Part 15.7: Short-Range Optical Wireless
Communications", IEEE Std 802.15.7-2018,
DOI 10.1109/IEEESTD.2019.8697198, April 2019,
<https://ieeexplore.ieee.org/document/8697198>.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462,
December 1998, <https://www.rfc-editor.org/info/rfc2462>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<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, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[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, September 2007,
<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, September 2011,
<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, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <https://www.rfc-editor.org/info/rfc7136>.
Choi, et al. Expires 24 April 2026 [Page 15]
RFC IPv6 over OWC October 2025
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<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, November
2014, <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, October 2015,
<https://www.rfc-editor.org/info/rfc7668>.
[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, November 2018,
<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, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.
8.2. Informative References
[IEEE802.11bb-2023]
IEEE, "IEEE Standard for Information Technology--
Telecommunications and Information Exchange between
Systems Local and Metropolitan Area Networks--Specific
Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 6:
Light Communications", IEEE Std 802.11bb-2023, June 2023,
<https://standards.ieee.org/ieee/802.11bb/10823>.
[IEEE802.15.13-2023]
IEEE, "IEEE Standard for Multi-Gigabit per Second Optical
Wireless Communications (OWC), with Ranges up to 200 m,
for Both Stationary and Mobile Devices", IEEE
Std 802.15.13-2023, February 2023,
<https://standards.ieee.org/ieee/802.15.13/10269>.
Choi, et al. Expires 24 April 2026 [Page 16]
RFC IPv6 over OWC October 2025
[IEEE802.15.7a]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Part 15.7: Short-Range Optical Wireless
Communications Amendment 1: Higher Rate, Longer Range
Optical Camera Communication (OCC)", IEEE Std 802.15.7a-
2024, December 2024,
<https://standards.ieee.org/ieee/802.15.7a/10367>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[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, August 2007,
<https://www.rfc-editor.org/info/rfc4919>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Acknowledgements
We are grateful to the members of the IETF 6lo Working Group. Carles
Gomez has been funded in part by the Spanish Government through
project PID2019-106808RA-I00 and PID2023-146378NB-I00, and by
Secretaria d'Universitats i Recerca del Departament d'Empresa i
Coneixement de la Generalitat de Catalunya 2017 through grant SGR 376
and 2021 throught grant SGR 00330.
Annex A. Example Use of Combined 6LoWPAN HC and SCHC
This annex presents an optional strategy and considerations for
combining 6LoWPAN and SCHC header compression techniques within IPv6
over OWC networks. The goal is to provide flexibility across
different deployment scenarios and traffic patterns. This strategy
is not a required part of the specification.
Choi, et al. Expires 24 April 2026 [Page 17]
RFC IPv6 over OWC October 2025
A.1 Motivation
OWC-based IPv6 networks can involve both low-latency, local
communication (e.g., between nearby sensor devices), and longer-range
or upstream communication (e.g., to cloud services). Each of these
communication patterns may benefit from different header compression
techniques.
6LoWPAN is lightweight and quasi-stateless, making it attractive for
devices with strict memory or processing constraints. 6LoWPAN is not
fully stateless because it also supports context-based compression
for specific prefixes or addresses, particularly in global
communication scenarios [RFC6282].
SCHC, on the other hand, may require more memory and processing due
to its stateful nature, but offers significantly higher compression
efficiency when header field values are predictable. In low bit-rate
technologies, SCHC’s higher compression ratio may lead to reduced
overall transmission time, offsetting the additional processing
overhead. Supporting both compression schemes can help address the
needs of heterogeneous devices and deployments.
A.2 Compression Selection Strategy
An OWC node is able to select an appropriate header compression
method based on the following contextual factors:
* Header Field Predictability: The key determinant is whether the
values of header fields can be predicted at the time of
compression. This impacts SCHC's effectiveness more than whether
traffic is periodic or event-driven.
* Traffic Characteristics: Although traffic may be periodic or
event-driven, what matters more is the structure and stability of
the header field values across packets. Structured, repeated
traffic patterns favor SCHC.
* Service Requirements: Delay-sensitive applications do not
automatically favor 6LoWPAN. While SCHC may involve higher
processing latency, its ability to reduce packet size can improve
transmission times—especially over low-data-rate links.
* Implementation Constraints: Devices with minimal memory and
processing capacity may prefer 6LoWPAN HC due to its simpler
encoding and lower overhead. More capable devices can benefit
from SCHC's higher efficiency.
Choi, et al. Expires 24 April 2026 [Page 18]
RFC IPv6 over OWC October 2025
* Interoperability Needs: In mixed deployments, legacy 6LoWPAN-only
nodes and SCHC-capable nodes may coexist. Supporting both schemes
ensures compatibility and facilitates gradual network upgrades.
Signaling mechanisms, such as the 'S' bit in the 6LoWPAN Capability
Option, can help indicate SCHC support and coordinate behavior across
devices.
Note: SCHC is not limited to LPWAN scenarios. It can be effective in
short-range, high-density deployments when header predictability and
compression efficiency are beneficial.
A.3 Example Scenarios
The following are example cases where combining 6LoWPAN and SCHC
might be beneficial:
* Mixed Generation Deployment: Older devices running legacy 6LoWPAN
stacks operate alongside newer SCHC-capable nodes, enabling
gradual network transition.
* Resource-Constrained Devices: Minimal hardware nodes use 6LoWPAN
HC, while gateways with more resources apply SCHC for upstream
traffic.
* Multi-Protocol Compression: SCHC is used to compress headers
beyond IPv6/UDP, including CoAP, ICMPv6, and even QUIC (as per
evolving specifications).
This hybrid approach allows for fine-grained optimization based on
deployment constraints, device diversity, and application-level
priorities.
Authors' Addresses
Younghwan Choi (editor)
Electronics and Telecommunications Research Institute
218 Gajeongno, Yuseung-gu
Daejeon
34129
South Korea
Phone: +82 42 860 1429
Email: yhc@etri.re.kr
Cheol-min Kim
Korea Electronics Technology Institute
25, Saenari-ro, Bundang-Gu, Seongnam-Si
Choi, et al. Expires 24 April 2026 [Page 19]
RFC IPv6 over OWC October 2025
Gyeonggi-do
13509
South Korea
Phone: +82 31 789 7595
Email: cmkim@keti.re.kr
Carles Gomez
Universitat Politecnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: carlesgo@entel.upc.edu
Choi, et al. Expires 24 April 2026 [Page 20]