Internet DRAFT - draft-choi-6lo-owc

draft-choi-6lo-owc







6lo                                                         Y. Choi, Ed.
Internet-Draft                                                      ETRI
Intended status: Standards Track                                C-M. Kim
Expires: 5 September 2024                                           KETI
                                                                C. Gomez
                                    Universitat Politecnica de Catalunya
                                                            4 March 2024


     Transmission of IPv6 Packets over Short-Range Optical Wireless
                             Communications
                         draft-choi-6lo-owc-02

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 5 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Choi, et al.            Expires 5 September 2024                [Page 1]

RFC                           IPv6 over OWC                   March 2024


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Short-Range Optical Wireless Communications . . . . . . . . .   4
     3.1.  Network Topologies  . . . . . . . . . . . . . . . . . . .   4
     3.2.  Protocol Stack of OWC . . . . . . . . . . . . . . . . . .   4
     3.3.  Addressing of OWC Devices . . . . . . . . . . . . . . . .   5
     3.4.  MTU and data rates of OWC Link Layer  . . . . . . . . . .   6
   4.  Specification of IPv6 over OWC  . . . . . . . . . . . . . . .   6
     4.1.  Protocol Stack  . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Stateless Address Autoconfiguration . . . . . . . . . . .   7
     4.3.  IPv6 Link-Local Address . . . . . . . . . . . . . . . . .   7
     4.4.  Neighbor Discovery  . . . . . . . . . . . . . . . . . . .   8
     4.5.  Header Compression  . . . . . . . . . . . . . . . . . . .   8
     4.6.  Fragmentation and Reassembly Considerations . . . . . . .   9
     4.7.  Unicast and Multicast Address Mapping . . . . . . . . . .   9
   5.  Internet Connectivity Scenarios . . . . . . . . . . . . . . .  10
     5.1.  OWC Device Network Connected to the Internet  . . . . . .  11
     5.2.  OWC Device Ad-hoc Network . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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.





Choi, et al.            Expires 5 September 2024                [Page 2]

RFC                           IPv6 over OWC                   March 2024


   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.






Choi, et al.            Expires 5 September 2024                [Page 3]

RFC                           IPv6 over OWC                   March 2024


   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



Choi, et al.            Expires 5 September 2024                [Page 4]

RFC                           IPv6 over OWC                   March 2024


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










Choi, et al.            Expires 5 September 2024                [Page 5]

RFC                           IPv6 over OWC                   March 2024


3.4.  MTU and data rates of OWC Link Layer

             +======+==============+=========================+
             | 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: MTU and Data Rates of IEEE 802.15.7

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




Choi, et al.            Expires 5 September 2024                [Page 6]

RFC                           IPv6 over OWC                   March 2024


                 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.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 5 September 2024                [Page 7]

RFC                           IPv6 over OWC                   March 2024


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

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



Choi, et al.            Expires 5 September 2024                [Page 8]

RFC                           IPv6 over OWC                   March 2024


   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


   In addition, OWC devices MAY utilize a mechanism for header
   compressed by Static Context Header Compression and fragmentation
   (SCHC) [RFC8724] if SCHC-compressed header is required.  For
   instance, SCHC may be used not only for UDP header compression, but
   for IPv6 headers, IPv6/UDP headers, or even IPv6/UDP/CoAP if CoAP is
   used (e.g., as in the SCHC HC over 802.15.4)

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].  However, for
   communication between an OWC device and other non-OWC devices on the
   Internet, probably the MTU is 1280 bytes (for the devices on the
   Internet) and Path MTU discovery [RFC8201] would be needed.

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 5 September 2024                [Page 9]

RFC                           IPv6 over OWC                   March 2024


                      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 5: 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








Choi, et al.            Expires 5 September 2024               [Page 10]

RFC                           IPv6 over OWC                   March 2024


5.1.  OWC Device Network Connected to the Internet

   Figure 6 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 6: 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 7.

                                    6LN                        6LN
                                     |                          |
                          OWC link ->|               OWC link ->|
                                     |                          |
         6LN ---------------------- 6LR ---------------------- 6LR
          .         OWC link                    OWC link        |
          .                                                     |
          .                                          OWC link ->|
          .                                                    6LN
          .                                                     .
          . < - - - - - - - - - -  Subnet - - - - - - - - - - > .

                   Figure 7: Isolated OWC Device Network


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




Choi, et al.            Expires 5 September 2024               [Page 11]

RFC                           IPv6 over OWC                   March 2024


6.  IANA Considerations

   This document has no IANA actions.

7.  Security Considerations

   [TBD]

8.  References

   [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, April 2019,
              <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, 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>.

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

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

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




Choi, et al.            Expires 5 September 2024               [Page 12]

RFC                           IPv6 over OWC                   March 2024


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

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

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

   [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, July 2017,
              <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, November 2018,
              <https://www.rfc-editor.org/info/rfc8505>.






Choi, et al.            Expires 5 September 2024               [Page 13]

RFC                           IPv6 over OWC                   March 2024


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

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
   Phone: +82 42 860 1429
   Email: yhc@etri.re.kr


   Cheol-min Kim
   Korea Electronics Technology Institute
   25, Saenari-ro, Bundang-Gu, Seongnam-Si
   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 5 September 2024               [Page 14]