One document matched: draft-thubert-6lo-inner-compression-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.20 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<rfc ipr="trust200902" docName="draft-thubert-6lo-inner-compression-00" category="std" updates="6282">
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc compact="no"?>
<front>
<title>6LoWPAN Inner Compression</title>
<author initials="P." surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization abbrev="Cisco">Cisco Systems</organization>
<address>
<postal>
<street>Building D - Regus</street> <street>45 Allee des Ormes</street> <street>BP1200</street>
<city>MOUGINS - Sophia Antipolis</city>
<code>06254</code>
<country>FRANCE</country>
</postal>
<phone>+33 4 97 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author initials="X" surname="Vilajosana" fullname="Xavier Vilajosana" >
<organization>Universitat Oberta de Catalunya</organization>
<address>
<postal>
<street>156 Rambla Poblenou</street>
<city>Barcelona</city>
<region>Catalonia</region>
<code>08018</code>
<country>Spain</country>
</postal>
<phone>+34 (646) 633 681</phone>
<email>xvilajosana@uoc.edu</email>
</address>
</author>
<author initials="S." surname="Duquennoy" fullname="Simon Duquennoy">
<organization>Inria</organization>
<address>
<postal>
<street>40, avenue Halley </street>
<city>Villeneuve d'Ascq</city>
<region></region>
<code>59650</code>
<country>France</country>
</postal>
<phone>+33 768227731</phone>
<email>simon.duquennoy@inria.fr</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>6lo</workgroup>
<abstract>
<t>This specification modifies 6LoWPAN stateless address compression to enable
the compression by 6LOWPAN_IPHC of non Link-Local addresses in an IP header when
a reference address can be found in an encapsulation.
.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving
energy, a very constrained resource in most cases. The other
constraints, such as the memory capacity and the duty cycling of the LLN
devices, derive from that primary concern. Energy is often available
from primary batteries that are expected to last for years, or is scavenged from the
environment in very limited quantities. Any protocol that is intended for
use in LLNs must be designed with the primary concern of saving energy as
a strict requirement.</t>
<t>Controlling the amount of data transmission is one possible venue to save
energy. In a number of LLN standards, the frame size is limited to much
smaller values than the IPv6 maximum transmission unit (MTU) of 1280 bytes.
In particular, an LLN that relies on the classical Physical Layer (PHY)
of IEEE 802.15.4 <xref target="IEEE802154"/> is limited to 127 bytes
per frame. The need to compress IPv6 packets over IEEE 802.15.4 led to
the <xref target="RFC6282">6LoWPAN Header Compression</xref> work (6LoWPAN-HC).
</t>
<t>6LoWPAN-HC is designed to support more than one IPv6 address per node and per
Interface Identifier (IID), an IID being typically derived from a MAC address to
optimize the compression. The stateless address compression modes (SAC/DAC=0)
enable the compression of Link Local Addresses only. The suffix is found either
in-line or in the MAC header or an encapsulating IP header. The other addresses,
Global and Unique-Local Addresses, can be only compressed with stateful address
compression modes (SAC/DAC=1), whereby the prefix is found in a context.
</t>
<t>In the case of an IP-in-IP encapsulation in a LLN, either or both the source
or the destination address in the inner header is usually derived from the same
prefix as the encapsulating header and could be compressed without a context.
This specification updates <xref target="RFC6282"/> stateless address compression
to use the prefixes found in encapsulating headers as compression reference as
opposed to the link local prefix.
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
<t>The Terminology used in this document is consistent with and incorporates that
described in `Terminology in Low power And Lossy Networks’ <xref target="RFC7102"/> and
<xref target="RFC7228"/>.</t>
<!--
<t>The term “byte” is used in its now customary sense as a synonym for
“octet”.</t>
-->
</section>
<section anchor="updating-rfc-6282" title="Updating RFC 6282">
<t>This draft updates the LOWPAN-IPHC compression specified in 6LoWPAN-HC
<xref target="RFC6282"/> in the cases where SAC=0 and where M=0 and DAC=0.
</t><t>
The change is that the prefix that is used as compression reference is not
necessarily derived from the link local prefix but may be obtained from a
preceding header.
</t><t>
If no prefix is located in a preceding header then the stateless compression
based on the link local prefix and specified in <xref target="RFC6282"/> still
applies.
</t><t>
Locating a prefix for the compression of the source address (SAC=0) is discussed
in <xref target="src"/> and <xref target="lorh"/>.
Locating a prefix for the compression of the destination address (M=0 and DAC=0)
is discussed in <xref target="dest"/> and <xref target="lorh"/>.
<!--
If SAC=0:
00: 128 bits. The full address is carried in-line.
01: 64 bits. The first 64-bits of the address are elided.
The value of those bits is the link-local prefix padded with
zeros. The remaining 64 bits are carried in-line.
10: 16 bits. The first 112 bits of the address are elided.
The value of the first 64 bits is the link-local prefix
padded with zeros. The following 64 bits are 0000:00ff:
fe00:XXXX, where XXXX are the 16 bits carried in-line.
11: 0 bits. The address is fully elided. The first 64 bits
of the address are the link-local prefix padded with zeros.
The remaining 64 bits are computed from the encapsulating
header (e.g., 802.15.4 or IPv6 source address) as specified
in Section 3.2.2.
If M=0 and DAC=0 This case matches SAC=0 but for the destination
address:
00: 128 bits. The full address is carried in-line.
01: 64 bits. The first 64-bits of the address are elided.
The value of those bits is the link-local prefix padded with
zeros. The remaining 64 bits are carried in-line.
10: 16 bits. The first 112 bits of the address are elided.
The value of the first 64 bits is the link-local prefix
padded with zeros. The following 64 bits are 0000:00ff:
fe00:XXXX, where XXXX are the 16 bits carried in-line.
11: 0 bits. The address is fully elided. The first 64 bits
of the address are the link-local prefix padded with zeros.
The remaining 64 bits are computed from the encapsulating
header (e.g., 802.15.4 or IPv6 destination address) as
specified in Section 3.2.2.
-->
</t>
</section>
<section anchor="srcdest" title="Compression References">
<t>
The native origin for a compression reference is in an IP-in-IP encapsulating
header. This is discussed in <xref target="src"/> and <xref target="dest"/>.
Other headers such as the <xref target="I-D.ietf-6lo-routing-dispatch">
6LoWPAN Routing Header</xref> (6LoRH) can be also serve as reference;
that particular case is discussed in <xref target="lorh"/>.
</t>
<section anchor="src" title="For Source IP From Encapsulating IP Header">
<t>If the IP header that is compressed with LoWPAN_IPHC is encapsulated in
another IP header, the compression reference is the source of that encapsulating
header, that is the address of the node that performed the encapsulation,
whether that encapsulating header was itself encapsulated again or not.
</t>
</section>
<section anchor="dest" title="For Destination IP From Encapsulating IP Header">
<t>
If the IP header that is compressed with LoWPAN_IPHC is encapsulated in
another IP header, the compression reference is the address of the destination
of the encapsulating IP packet, that is the node that eventually performs the
decapsulation of the IP header.
</t>
<t>
If a routing header is present in the encapsulating IP header chain, this is the
last address in the last routing header at the time the encapsulation is
generated. In the uncompressed form of a Routing Header type 3
<xref target="RFC6554"/>, it is swapped with the address of the destination at
the time the packet reaches it, and thus found in the IP header as opposed to
the routing header.
</t>
</section>
<section anchor="lorh" title="Preceding 6LoRH Header">
<t>
The <xref target="I-D.ietf-6lo-routing-dispatch">6LoWPAN Routing Header</xref>
specification documents a compression scheme for the RPL artifacts in data
packet. The compressed format places the artifacts in 6LoRH Headers that are
located before the LOWPAN_IPHC, even when there is not IP-in-IP encapsulation.
</t>
<t>
If there is no IP-in-IP encapsulation but the IP header that is compressed with
LoWPAN_IPHC is preceded in the compressed form by an RH3-6LoRH header, then the
last address in the last RH3-6LoRH header is the compression reference for the
destination address.
</t>
<t>
If there is an IP-in-IP encapsulation compressed with IP-in-IP-6LoRH, then the
address of the destination of the encapsulating IP packet is encoded in a
RH3-6LoRH as well, so the last address in the last RH3-6LoRH header is also the
compression reference for the destination address.
</t>
<t>
If there is no IP encapsulation but the IP header that is compressed with
LoWPAN_IPHC is preceded in the compressed form by an RPI-6LoRH header that
identifies a RPL DODAG <xref target="RFC6550"/>, then the address of the root
of the DODAG is the compression reference for the source address.
It is also the compression reference for the destination address in the absence
of an RH3-6LoRH header.
</t>
</section>
</section>
<section anchor="opers" title="Stateless Compression of the Source Address">
<t>This section covers the case of stateless address compression (SAC=0) of the
source address in a LOWPAN-IPHC.
</t>
<t>
If a compression reference <xref target="src"/> cannot be found, then
<xref target="RFC6282"/> applies.
Else, the compression depends on the value of the SAM bits as follows:
<list style="hanging">
<t hangText="00:"> 128 bits. The full address is carried in-line</t>
<t hangText="01:"> 64 bits. The first 64-bits of the address are elided and
obtained from the compression reference; the remaining 64 bits are carried in-line</t>
<t hangText="10:"> 16 bits. The first 112 bits of the address are elided and
obtained from the compression reference; the remaining 16 bits are carried in-line</t>
<t hangText="11:"> 0 bits. The address is fully elided, it is the same as
the compression reference.</t>
</list>
</t>
</section>
<section anchor="operd" title="Stateless Compression of the Destination Address">
<t>This section covers the case of stateless unicast address compression
(M=0, DAC=0) of the destination address in a LOWPAN-IPHC.
</t><t>
If a compression reference <xref target="dest"/> cannot be found, then
<xref target="RFC6282"/> applies.
Else, the compression depends on the value of the DAM bits as follows:
<list style="hanging">
<t hangText="00:"> 128 bits. The full address is carried in-line</t>
<t hangText="01:"> 64 bits. The first 64-bits of the address are elided and
obtained from the compression reference; the remaining 64 bits are carried in-line</t>
<t hangText="10:"> 16 bits. The first 112 bits of the address are elided and
obtained from the compression reference; the remaining 16 bits are carried in-line</t>
<t hangText="11:"> 0 bits. The address is fully elided, it is the same as
the compression reference.</t>
</list>
</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The security considerations of <xref target="RFC4944"/> and <xref target="RFC6282"/> apply.</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document does not have requirements for IANA.</t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The authors wish to thank Thomas Watteyne, Maria-Rita Palatella, Aurélie Sfez
and Miguel Angel Reina Ortega for organizing the 6TiSCH PlugTest with the ETSI.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4944"?>
<?rfc include="reference.RFC.6282"?>
<?rfc include='reference.I-D.ietf-6lo-routing-dispatch'?>
<reference anchor="IEEE802154" >
<front>
<title>IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks</title>
<author >
<organization>IEEE standard for Information Technology</organization>
</author>
<date/>
</front>
</reference>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.6550"?>
<?rfc include="reference.RFC.6554"?>
<?rfc include="reference.RFC.7102"?>
<?rfc include="reference.RFC.7228"?>
<?rfc include='reference.I-D.ietf-6tisch-architecture'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:10:04 |