One document matched: draft-gomez-lpwan-ipv6-analysis-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no"?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-gomez-lpwan-ipv6-analysis-00"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="IPv6 over LPWAN analysis">
Analysis of IPv6 over LPWAN: design space and challenges
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Carles Gomez" initials="C.G" surname="Gomez">
<organization>UPC/i2CAT</organization>
<address>
<postal>
<street>C/Esteve Terradas, 7</street>
<city>Castelldefels</city>
<region/>
<code>08860</code>
<country>Spain</country>
</postal>
<phone/>
<facsimile/>
<email>carlesgo@entel.upc.edu</email>
<uri/>
</address>
</author>
<author fullname="Josep Paradells" initials="J.P" surname="Paradells">
<organization>UPC/i2CAT</organization>
<address>
<postal>
<street>C/Jordi Girona, 1-3</street>
<city>Barcelona</city>
<region/>
<code>08034</code>
<country>Spain</country>
</postal>
<phone/>
<facsimile/>
<email>josep.paradells@entel.upc.edu</email>
<uri/>
</address>
</author>
<author fullname="Jon Crowcroft" initials="J.C" surname="Crowcroft">
<organization>University of Cambridge</organization>
<address>
<postal>
<street>JJ Thomson Avenue</street>
<city>Cambridge</city>
<region>CB3 0FD</region>
<code/>
<country>United Kingdom</country>
</postal>
<phone/>
<facsimile/>
<email>jon.crowcroft@cl.cam.ac.uk</email>
<uri/>
</address>
</author>
<!-- uri and facsimile elements may also be added -->
<date month="March" year="2016"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>INT</area>
<workgroup>Network Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!---->
<abstract>
<t> Connecting Low Power Wide Area Networks (LPWANs) to the Internet is expected to provide significant benefits to these networks in terms of interoperability, application deployment, and management, among others. However, the constraints of LPWANs, often more extreme than those of typical 6Lo(WPAN) technologies, constitute a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN. Considering the typical characteristics of LPWAN technologies, this document analyzes the design space and challenges related with enabling IPv6 over LPWAN.
</t>
</abstract>
</front>
<middle>
<section title="Introduction ">
<t>Low Power Wide Area Network (LPWAN) technologies define long range, low bit rate and low power wireless interfaces that are used for control and monitoring applications. Examples of LPWAN technologies include LoRa, SigFox, IEEE 802.15.4k LECIM, Weightless, etc. <xref
target="I-D.minaburo-lp-wan-gap-analysis"/>.</t>
<t>Connecting LPWANs to the Internet is expected to provide significant benefits to these networks in terms of interoperability, application deployment, and management, among others. Therefore, the support of IPv6 over LPWAN is a fundamental aspect to be examined for LPWAN Internet connectivity.
</t>
<t> Several technologies that exhibit significant constraints in various dimensions have exploited the 6LoWPAN suite of specifications (<xref
target="RFC4944"/><xref
target="RFC6282"/><xref
target="RFC6775"/>) to support IPv6 <xref
target="I-D.hong-6lo-use-cases"/>. 6LoWPAN, which was originally designed for IEEE 802.15.4 networks, provides a frame format, address autoconfiguration, fragmentation, header compression, and optimized IPv6 neighbor discovery. </t>
<t>However, the constraints of LPWANs, often more extreme than those of typical 6Lo(WPAN) technologies, constitute a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN. LPWANs are characterized by device constraints (in terms of processing capacity, memory, and energy availability), and specially, link constraints, such as i) very low layer two payload size (from ~10 to ~100 bytes), ii) very low bit rate (from ~10 bit/s to ~100 kbit/s), and iii) in some specific technologies, further message rate constraints (e.g. between ~0.1 message/minute and ~1 message/minute) due to regional regulations that limit the duty cycle. </t>
<t>In some cases the 6LoWPAN functionality may be used to enable IPv6 over specific LPWAN technologies (with the level of adaptation done in the IPv6 over foo documents produced by the IETF 6lo WG), maintaining good performance. However, in the most challenged LPWAN technologies and/or configurations, further optimization and/or tuning of the 6LoWPAN functionality is required for efficient operation. This document analyzes the design space and challenges of enabling IPv6 over LPWAN. </t>
<section title="Conventions used in this document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/></t>
</section>
</section>
<section title="Protocol stack">
<t>
In the design of an IPv6 over foo adaptation layer, if more than one layer (other than the physical layer) is supported by the target technology, a crucial decision is which lower layer will interface with the adaptation layer. The layer(s) below the adaptation layer must provide the functionality to enable a link, i.e. "a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP" <xref
target="RFC4861"/>. </t>
<t>
In addition to the above requirement, further aspects to consider in the mentioned decision include lower layer support of fragmentation (see Section 5), overhead, and the ability of multplexing upper layer protocols.</t>
</section>
<section title="Network topology and device roles">
<t>As of the writing, LPWAN technologies typically follow the star topology, whereby the end devices are connected through a direct link with a central device. In that case, the end devices and the central device will act as 6LoWPAN Nodes (6LN) and 6LoWPAN Border Router (6LBR), respectively. The 6LBR may provide Internet connectivity (see <xref
target="fig.subnetmodel"/>).
</t>
</section>
<section title="IPv6 subnet model">
<t>As IPv6 over LPWAN is intended for constrained nodes, and for Internet of Things use cases and environments, the complexity of implementing a separate subnet on each link and routing between the
subnets appears to be excessive. For LPWAN, the benefits
of treating the collection of links of the network as a single multilink subnet rather than a multiplicity of separate subnets are considered to outweigh the multilink model's drawbacks as described in <xref
target="RFC4903"/>.
</t>
<figure anchor="fig.subnetmodel"
title="LPWAN connected to the Internet">
<artwork><![CDATA[
/
.---------------. /
/ 6LN \ /
/ \ \ /
| \ | /
| 6LN ----------- 6LBR ----- | Internet
| <--Link--> / | \
\ / / \
\ 6LN / \
'---------------' \
\
<------ Subnet -----><-- IPv6 connection -->
to Internet
]]></artwork>
</figure>
<t>
In the multilink subnet model, link-local multicast communications can
happen only within a single link; thus, 6LN-to-6LN
communications using link-local addresses are not possible. 6LNs
connected to the same 6LBR have to communicate with each other by
using the shared prefix used on the subnet.
</t>
</section>
<section title="Address autoconfiguration">
<t>In the ambit of 6Lo(WPAN) technologies, traditionally, Interface Identifiers (IIDs) have been derived from link layer identifiers <xref
target="RFC4944"/> . This allows optimizations such as header compression. Nevertheless, due to privacy concerns, LPWAN devices should not be configured to embed their link layer address in the IID by default (see Section 3.2.2 of <xref
target="RFC4903"/>, and <xref
target="I-D.ietf-6man-default-iids"/>).
</t>
</section>
<section title="Fragmentation">
<t>IPv6 requires an MTU of 1280 bytes <xref
target="RFC2460"/> . Therefore, given the low maximum payload size of LPWAN technologies, fragmentation is needed.
</t>
<t>If a layer of an LPWAN technology supports fragmentation, proper analysis has to be carried out to decide whether the fragmentation functionality provided by the lower layer or fragmentation at the adaptation layer should be used. Otherwise, fragmentation functionality shall be used at the adaptation layer.
</t>
<t>6LoWPAN defined a fragmentation mechanism and a fragmentation header to support the transmission of IPv6 packets over IEEE 802.15.4 networks <xref
target="RFC4944"/> . While the 6LoWPAN fragmentation header is appropriate for IEEE 802.15.4-2003 (which has a frame payload size of 81-102 bytes), it is not suitable for several LPWAN technologies, many of which have a maximum payload size that is one order of magnitude below that of IEEE 802.15.4-2003. The overhead of the 6LoWPAN fragmentation header is high, considering the reduced payload size of LPWAN technologies and the limited energy availability of the devices using such technologies. Furthermore, its datagram offset field is expressed in increments of eight octets. In some LPWAN technologies, the 6LoWPAN fragmentation header plus eight octets from the original datagram exceeds the available space in the layer two payload. To overcome these limitations, an optimized 6LoWPAN fragmentation header for LPWAN has been defined in <xref target="I-D.gomez-lpwan-fragmentation-header"/>.
</t>
</section>
<section title="Neighbor discovery">
<t>6LoWPAN Neighbor Discovery <xref
target="RFC6775"/> defined optimizations to IPv6 Neighbor Discovery <xref
target="RFC4861"/> , in order to adapt functionality of the latter for networks of devices using IEEE 802.15.4 or similar technologies. The optimizations comprise host-initiated interactions to allow for sleeping hosts, replacement of multicast-based address resolution for hosts by an address registration mechanism, multihop extensions for prefix distribution and duplicate address detection (note that these are not needed in a star topology network), and support for 6LoWPAN header compression.
</t>
<t>6LoWPAN Neighor Discovery may be used in LPWAN networks. However, the relative overhead incurred will depend on the LPWAN technology used (and on its configuration, if appropriate). In certain LPWAN setups (with a maximum payload size above ~60 bytes, and duty-cycle-free or equivalent operation), an RS/RA/NS/NA exchange may be completed in a few seconds, without incurring packet fragmentation. In others (with a maximum payload size of ~10 bytes, and a message rate of ~0.1 message/minute), the same exchange may take a few hours, leading to severe fragmentation and consuming a significant amount of the available network resources. See Annex A for an analysis of the 6LoWPAN Neighbor Discovery message sizes.
</t>
<t>6LoWPAN Neighbor Discovery behavior may be tuned through the use of appropriate values for the default Router Lifetime, the Valid Lifetime in the PIOs, and the Valid Lifetime in the 6CO, as well as the address Registration Lifetime.
</t>
<t>The Router Lifetime, which is present in RAs, may be as high as 18.2 hours. The Valid Lifetime in the PIO indicates the time of validity of the prefix indicated in the PIO, and it is possible to encode a value of infinity for this lifetime. The Valid Lifetime in the 6CO, which indicates the time of validity of the related context for header compression, may be as high as 45 days. A 6LN should unicast an RS to the router before expiration of any of these lifetimes. On the other hand, the address Registration Lifetime determines the periodicity with which a 6LN has to perform address reregistration with the router, and may be as high as 45 days.
</t>
<t>Therefore, 6LoWPAN Neighbor Discovery supports relatively high periods without generating messages (the shortest being the maximum Router Lifetime). However, there exists a trade-off between Neighbor Discovery message overhead and reactivity to network changes (potentially affecting network connectivity) that must be assessed. On the other hand, the most challenged LPWAN setups may require the definition of functionality beyond the limits of <xref target="RFC6775"/>.
</t>
</section>
<section title="Header compression">
<t> <xref target="RFC6282"/> defines stateless and stateful header compression for 6LoWPAN networks. This functionality is highly required in LPWAN, given the extreme resource constraints of these networks.
</t>
<t> <xref target="RFC6282"/> defines a two-byte base encoding. To enable context-based compression of global addresses, a further byte is needed to encode source and destination context. Such compression may cover prefixes or complete, 128-bit IPv6 addresses. In the most minimalistic case, assuming that the IPv6 header fields allow the maximum possible degree of compression, an IPv6 header comprising global IPv6 addresses may be compressed to a size of 3 bytes.
</t>
<t>Contexts may be disseminated by using the 6CO in RA messages. Up to 16 contexts may be defined. However, note that each 6CO for a full IPv6 address context adds 24 bytes to the RA message (Annex A), which incurs an amount of overhead which is not negligible for certain LPWAN setups.
</t>
<t>If the network follows the star topology, optimizations for header compression that leverage this type of network topology may be used (see section 3.2.4 of <xref target="RFC7668"/>).
</t>
</section>
<section title="Unicast and multicast mapping">
<t>In some LPWAN technologies, layer two multicast is not supported. In that case, if the network topology is a star, the solution and considerations of section 3.2.5 of <xref target="RFC7668"/> may be applied.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<!-- Possibly a 'Contributors' section ... -->
<section anchor="ACKs" title="Acknowledgments">
<t>In section 4, the authors have reused part of the content
available in section 3.2.1 of RFC 7668, and would like to thank the authors of that specification.</t>
<t>Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose Castillejo grant CAS15/00336. His contribution to this work has been carried out during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge.</t>
</section>
<section title="Annex A. RFC 6775 message size analysis">
<t>-- Router Solicitation (RS), without options: 8 bytes</t>
<t>-- Router Advertisement (RA), without options: 16 bytes</t>
<t>-- Neighbor Solicitation (NS), without options: 24 bytes </t>
<t>-- Neighbor Advertisement (NA), without options: 24 bytes</t>
<t>-- Source Link-Layer Address Option (SLLAO): 2 bytes + link layer address size (bytes)</t>
<t>-- Prefix Information Option (PIO): 16 bytes + prefix size (bytes)</t>
<t>-- 6LoWPAN Context Option (6CO): 8 bytes + context prefix size (bytes)</t>
<t>-- Address Registration Option (ARO): 16 bytes</t>
<t>For the following calculations, a Link Layer Address (LLA) of 4 bytes, a prefix of 8 bytes, and a context prefix of 16 bytes (for maximum compression) have been assumed. A single 6CO is assumed, as a minimalistic use of header compression. (Note: the Authoritative Border Router Option (ABRO) will not be present in networks that follow the star topology.)</t>
<t>
Message sizes: </t>
<t>-- Size of RS with SLLAO = 14 bytes</t>
<t>-- Size of RA with SLLAO, PIO and 6CO = 62 bytes</t>
<t>-- Size of NS with ARO and SLLAO = 46 bytes</t>
<t>-- Size of NA + ARO = 40 bytes
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include='reference.RFC.2119.xml'?>
<?rfc include='reference.RFC.2460.xml'?>
<?rfc include='reference.RFC.4861.xml'?>
<?rfc include='reference.RFC.4903.xml'?>
<?rfc include='reference.RFC.4944.xml'?>
<?rfc include='reference.RFC.6282.xml'?>
<?rfc include='reference.RFC.6775.xml'?>
<?rfc include='reference.RFC.7668.xml'?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include='reference.I-D.minaburo-lp-wan-gap-analysis'?>
<?rfc include='reference.I-D.hong-6lo-use-cases'?>
<?rfc include='reference.I-D.ietf-6man-default-iids'?>
<?rfc include='reference.I-D.gomez-lpwan-fragmentation-header'?>
</references>
<!-- -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:20:45 |