One document matched: draft-ietf-6lo-lowpanz-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-6lo-lowpanz-07" ipr="trust200902">
<front>
<title abbrev="IPv6 over G.9959">Transmission of IPv6 packets over ITU-T
G.9959 Networks</title>
<author fullname="Anders Brandt" initials="A." surname="Brandt">
<organization>Sigma Designs</organization>
<address>
<postal>
<street>Emdrupvej 26A, 1.</street>
<city>Copenhagen O</city>
<code>2100</code>
<region/>
<country>Denmark</country>
</postal>
<phone/>
<facsimile/>
<email>anders_brandt@sigmadesigns.com</email>
</address>
</author>
<author fullname="Jakob Buron" initials="J." surname="Buron">
<organization>Sigma Designs</organization>
<address>
<postal>
<street>Emdrupvej 26A, 1.</street>
<city>Copenhagen O</city>
<code>2100</code>
<region/>
<country>Denmark</country>
</postal>
<phone/>
<facsimile/>
<email>jakob_buron@sigmadesigns.com</email>
</address>
</author>
<date day="22" month="September" year="2014"/>
<area>Internet Area</area>
<workgroup>IPv6 over Networks of Resource-constrained Nodes (6lo)
WG</workgroup>
<abstract>
<t>This document describes the frame format for transmission of IPv6
packets and a method of forming IPv6 link-local addresses and
statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.</t>
</abstract>
<note title="Requirements Language">
<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>
</note>
</front>
<middle>
<section title="Introduction">
<t>The ITU-T G.9959 recommendation <xref target="G.9959"/> targets
low-power Personal Area Networks (PANs). This document defines the frame
format for transmission of IPv6 <xref target="RFC2460"/> packets as well
as the formation of IPv6 link-local addresses and statelessly
autoconfigured IPv6 addresses on G.9959 networks.</t>
<t>The general approach is to adapt elements of <xref target="RFC4944"/>
to G.9959 networks. G.9959 provides a Segmentation and Reassembly (SAR)
layer for transmission of datagrams larger than the G.9959 MAC PDU.</t>
<t><xref target="RFC6775"/> updates <xref target="RFC4944"/> by
specifying 6LoWPAN optimizations for IPv6 Neighbor Discovery (ND)
(originally defined by <xref target="RFC4861"/>). This document limits
the use of <xref target="RFC6775"/> to prefix and Context ID assignment.
An IID may be constructed from a G.9959 link-layer address, leading to a
"link-layer-derived IPv6 address". If using that method, Duplicate
Address Detection (DAD) is not needed. Alternatively, IPv6 addresses may
be assigned centrally via DHCP, leading to a "non-link-layer-derived
IPv6 address". Address registration is only needed in certain cases.</t>
<t>In addition to IPv6 application communication, the frame format
defined in this document may be used by IPv6 routing protocols such as
<xref target="RFC6550">RPL</xref> or <xref
target="RFC6997">P2P-RPL</xref> to implement IPv6 routing over G.9959
networks.</t>
<t>The encapsulation frame defined by this specification may optionally
be transported via mesh routing below the 6LoWPAN layer. Mesh-under and
route-over routing protocol specifications are out of scope of this
document.</t>
<section title="Terms used">
<t>6LoWPAN: IPv6-based Low-power Personal Area Network</t>
<t>ABR: Authoritative 6LBR (<xref target="RFC6775"/>)</t>
<t>Ack: Acknowedgement</t>
<t>AES: Advanced Encryption Scheme</t>
<t>CID: Context Identifier (<xref target="RFC6775"/>)</t>
<t>DAD: Duplicate Address Detection (<xref target="RFC6775"/>)</t>
<t>DHCPv6: Dynamic Host Configuration Protocol for IPv6 (<xref
target="RFC3315"/>)</t>
<t>EUI-64: Extended Unique Identifier (<xref target="EUI64"/>)</t>
<t>G.9959: Short range, narrow-band digital radiocommunication
transceiver (<xref target="G.9959"/>)</t>
<t>GHC: Generic Header Compression (<xref target="RFC_TBD_GHC"/>)</t>
<t>HomeID: G.9959 Link-Layer Network Identifier</t>
<t>IID: Interface IDentifier</t>
<t>Link-layer-derived address: IPv6 Address constructed on basis of
link layer address information</t>
<t>MAC: Media Access Control</t>
<t>Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer</t>
<t>MTU: Maximum Transmission Unit</t>
<t>ND: Neighbor discovery (<xref target="RFC4861"/>, <xref
target="RFC6775"/>)</t>
<t>NodeID: G.9959 Link-Layer Node Identifier</t>
<t>Non-link-layer-derived address: IPv6 Address assigned by a managed
process, e.g. DHCPv6.</t>
<t>NVM: Non-volatile Memory</t>
<t>P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power
and Lossy Networks (<xref target="RFC6997"/>)</t>
<t>PAN: Personal Area Network</t>
<t>PDU: Protocol Data Unit</t>
<t>PHY: Physical Layer</t>
<t>RA: Router Advertisement (<xref target="RFC4861"/>, <xref
target="RFC6775"/>)</t>
<t>Route-over: Forwarding via IP routing above the 6LoWPAN layer</t>
<t>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (<xref
target="RFC6550"/>)</t>
<t>SAR: G.9959 Segmentation And Reassembly</t>
<t>ULA: Unique Local Address <xref target="RFC4193"/></t>
</section>
</section>
<section title="G.9959 parameters to use for IPv6 transport">
<t>This chapter outlines properties applying to the PHY and MAC of
G.9959 and how to use these for IPv6 transport.</t>
<section anchor="ChapterG9959_AddressingMode" title="Addressing mode">
<t>G.9959 defines how a unique 32-bit HomeID network identifier is
assigned by a network controller and how an 8-bit NodeID host
identifier is allocated to each node. NodeIDs are unique within the
network identified by the HomeID. The G.9959 HomeID represents an IPv6
subnet which is identified by one or more IPv6 prefixes.</t>
<t>An IPv6 host MUST construct its link-local IPv6 address from the
link-layer-derived IID in order to facilitate IP header compression as
described in <xref target="RFC6282"/>.</t>
<t>A node interface MAY support the M flag of the RA message for the
construction of routable IPv6 addresses. A cost optimized node
implementation may save memory by skipping support for the M flag. The
M flag MUST be interpreted as defined in <xref
target="FigMflagSupportAndInterpretation"/>.</t>
<figure anchor="FigMflagSupportAndInterpretation"
title="RA M flag support and interpretation">
<artwork><![CDATA[ +--------+--------+---------------------------------------------+
| M Flag | M flag | Required node behavior |
| support| value | |
+--------+--------+---------------------------------------------+
| No |(ignore)| Node MUST use link-layer-derived addressing |
+--------+--------+---------------------------------------------+
| Yes | 0 | Node MUST use link-layer-derived addressing |
| +--------+---------------------------------------------+
| | 1 | Node MUST use DHCPv6 based addressing and |
| | | Node MUST comply fully with [RFC6775] |
+--------+--------+---------------------------------------------+ ]]></artwork>
</figure>
<t>A node that uses DHCPv6 based addressing MUST comply fully with the
text of <xref target="RFC6775"/>.</t>
<t>A word of caution: since HomeIDs and NodeIDs are handed out by a
network controller function during inclusion, identifier validity and
uniqueness is limited by the lifetime of the network membership. This
can be cut short by a mishap occurring to the network controller.
Having a single point of failure at the network controller suggests
that high-reliability network deployments may benefit from a redundant
network controller function.</t>
<t>This warning applies to link-layer-derived addressing as well as to
non-link-layer-derived addressing deployments.</t>
</section>
<section title="IPv6 Multicast support">
<t><xref target="RFC3819"/> recommends that IP subnetworks support
(subnet-wide) multicast. G.9959 supports direct-range IPv6 multicast
while subnet-wide multicast is not supported natively by G.9959.
Subnet-wide multicast may be provided by an IP routing protocol or a
mesh routing protocol operating below the 6LoWPAN layer. Routing
protocol specifications are out of scope of this document.</t>
<t>IPv6 multicast packets MUST be carried via G.9959 broadcast.</t>
<t>As per <xref target="G.9959"/>, this is accomplished as
follows:</t>
<t><list style="numbers">
<t>The destination HomeID of the G.9959 MAC PDU MUST be the HomeID
of the network</t>
<t>The destination NodeID of the G.9959 MAC PDU MUST be the
broadcast NodeID (0xff)</t>
</list>G.9959 broadcast MAC PDUs are only intercepted by nodes
within the network identified by the HomeID.</t>
</section>
<section title="G.9959 MAC PDU size and IPv6 MTU">
<t>IPv6 packets MUST be transmitted using G.9959 transmission profile
R3 or higher.</t>
<t><xref target="RFC2460"/> specifies that any link that cannot convey
a 1280-octet packet in one piece, must provide link-specific
fragmentation and reassembly at a layer below IPv6.</t>
<t>G.9959 provides Segmentation And Reassembly for payloads up to 1350
octets. IPv6 Header Compression <xref target="RFC6282"/> improves the
chances that a short IPv6 packet can fit into a single G.9959 frame.
Therefore, section <xref
target="ChapterLoWPAN_AdaptationLayerAndFrameFormat"/> specifies that
<xref target="RFC6282"/> MUST be supported. With the mandatory
link-layer security enabled, a G.9959 R3 MAC PDU may accommodate
6LoWPAN datagrams of up to 130 octets without triggering G.9959
Segmentation and Reassembly (SAR). Longer 6LoWPAN datagrams will lead
to the transmission of multiple G.9959 PDUs.</t>
</section>
<section title="Transmission status indications">
<t>The G.9959 MAC layer provides native acknowledgement and
retransmission of MAC PDUs. The G.9959 SAR layer does the same for
larger datagrams. A mesh routing layer may provide a similar feature
for routed communication. An IPv6 routing stack communicating over
G.9959 may utilize link-layer status indications such as delivery
confirmation and Ack timeout from the MAC layer.</t>
</section>
<section title="Transmission security">
<t>Implementations claiming conformance with this document MUST enable
G.9959 shared network key security.</t>
<t>The shared network key is intended to address security requirements
in the home at the normal security requirements level. For
applications with high or very high requirements on confidentiality
and/or integrity, additional application layer security measures for
end-to-end authentication and encryption may need to be applied. (The
availability of the network relies on the security properties of the
network key in any case)</t>
</section>
</section>
<section anchor="ChapterLoWPAN_AdaptationLayerAndFrameFormat"
title="6LoWPAN Adaptation Layer and Frame Format">
<t>The 6LoWPAN encapsulation formats defined in this chapter are carried
as payload in the G.9959 MAC PDU. IPv6 header compression <xref
target="RFC6282"/> MUST be supported by implementations of this
specification. Further, implementations MAY support Generic Header
Compression (GHC) <xref target="RFC_TBD_GHC"/>. A node implementing
<xref target="RFC_TBD_GHC"/> MUST probe its peers for GHC support before
applying GHC compression.</t>
<t>All 6LoWPAN datagrams transported over G.9959 are prefixed by a
6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this
encapsulation header stack. Each header in the header stack contains a
header type followed by zero or more header fields. An IPv6 header stack
may contain, in the following order, addressing, hop-by-hop options,
routing, fragmentation, destination options, and finally payload <xref
target="RFC2460"/>. The 6LoWPAN header format is structured the same
way. Currently only one payload option is defined for the G.9959 6LoWPAN
header format.</t>
<t>The definition of 6LoWPAN headers consists of the dispatch value, the
definition of the header fields that follow, and their ordering
constraints relative to all other headers. Although the header stack
structure provides a mechanism to address future demands on the 6LoWPAN
adaptation layer, it is not intended to provide general purpose
extensibility.</t>
<t>An example of a complete G.9959 6LoWPAN datagram can be found in
<xref target="appendix_datagram_example"/>.</t>
<section anchor="DispatchType" title="Dispatch Header">
<t>The dispatch header is shown below:<vspace blankLines="1"/></t>
<figure anchor="FigDispatchTypeAndHeader"
title="Dispatch Type and Header">
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6LoWPAN CmdCls| Dispatch | Type-specific header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST
carry the value 0x4F <xref target="G.9959"/>. The value is assigned by
the ITU-T and specifies that the following bits are a 6LoWPAN
encapsulated datagram. 6LoWPAN protocols MUST ignore the G.9959 frame
if the 6LoWPAN Command Class identifier deviates from 0x4F.</t>
<t>Dispatch: Identifies the header type immediately following the
Dispatch Header.</t>
<t>Type-specific header: A header determined by the Dispatch
Header.</t>
<t>The dispatch value may be treated as an unstructured namespace.
Only a few symbols are required to represent current 6LoWPAN
functionality. Although some additional savings could be achieved by
encoding additional functionality into the dispatch byte, these
measures would tend to constrain the ability to address future
alternatives.</t>
<t>Dispatch values used in this specification are compatible with the
dispatch values defined by <xref target="RFC4944"/> and <xref
target="RFC6282"/>.</t>
<figure anchor="FigDispatchValueBitPattern" title="Dispatch values">
<artwork><![CDATA[+------------+------------------------------------------+-----------+
| Pattern | Header Type | Reference |
+------------+------------------------------------------+-----------+
| 01 1xxxxx | 6LoWPAN_IPHC - Compressed IPv6 Addresses | [RFC6282] |
+------------+------------------------------------------+-----------+
All other Dispatch values are unassigned in this document.]]></artwork>
</figure>
<t>6LoWPAN_IPHC: IPv6 Header Compression. Refer to <xref
target="RFC6282"/>.</t>
</section>
</section>
<section anchor="LowpanAddressing" title="6LoWPAN addressing">
<t>IPv6 addresses may be autoconfigured from IIDs which may again be
constructed from link-layer address information to save memory in
devices and to facilitate efficient IP header compression as per <xref
target="RFC6282"/>. Link-layer-derived addresses have a static nature
and may involuntarily expose private usage data on public networks.
Refer to <xref target="Privacy"/>.</t>
<t>A NodeID is mapped into an IEEE EUI-64 identifier as follows:<vspace
blankLines="1"/></t>
<figure anchor="FigCompressibleIID"
title="Constructing a compressible IID">
<artwork><![CDATA[ IID = 0000:00ff:fe00:YYXX]]></artwork>
</figure>
<t>where XX carries the G.9959 NodeID and YY is a one byte value chosen
by the individual node. The default YY value MUST be zero. A node MAY
use other values of YY than zero to form additional IIDs in order to
instantiate multiple IPv6 interfaces. The YY value MUST be ignored when
computing the corresponding NodeID (the XX value) from an IID.</t>
<t>The method of constructing IIDs from the link-layer address obviously
does not support addresses assigned or constructed by other means. A
node MUST NOT compute the NodeID from the IID if the first 6 bytes of
the IID do not comply with the format defined in <xref
target="FigCompressibleIID"/>. In that case, the address resolution
mechanisms of RFC 6775 apply.</t>
<section anchor="StatelessAddressAutoconfiguration"
title="Stateless Address Autoconfiguration of routable IPv6 addresses">
<t>The IID defined above MUST be used whether autoconfiguring a ULA
IPv6 address <xref target="RFC4193"/> or a globally routable IPv6
address <xref target="RFC3587"/> in G.9959 subnets.</t>
</section>
<section anchor="ChapterIPv6_LinkLocalAddress"
title="IPv6 Link Local Address">
<t>The IPv6 link-local address <xref target="RFC4291"/> for a G.9959
interface is formed by appending the IID defined above to the IPv6
link local prefix FE80::/64.</t>
<t>The "Universal/Local" (U/L) bit MUST be set to zero in keeping with
the fact that this is not a globally unique value <xref
target="EUI64"/>.</t>
<t>The resulting link local address is formed as follows:<vspace
blankLines="1"/></t>
<figure anchor="FigIPv6_LinkLocalAddress"
title="IPv6 Link Local Address">
<artwork><![CDATA[ 10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier (IID) |
+----------+-----------------------+----------------------------+]]></artwork>
</figure>
<t><vspace blankLines="1"/></t>
</section>
<section anchor="UnicastAddressMapping" title="Unicast Address Mapping">
<t>The address resolution procedure for mapping IPv6 unicast addresses
into G.9959 link-layer addresses follows the general description in
Section 7.2 of <xref target="RFC4861"/>. The Source/Target Link-layer
Address option MUST have the following form when the link layer is
G.9959.<vspace blankLines="1"/></t>
<figure anchor="FigIPv6_UnicastAddressMapping"
title="IPv6 Unicast Address Mapping">
<artwork><![CDATA[ 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+- -+
| (All zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><vspace blankLines="1"/>Option fields:</t>
<t>Type: The value 1 signifies the Source Link-layer address. The
value 2 signifies the Destination Link-layer address.</t>
<t>Length: This is the length of this option (including the type and
length fields) in units of 8 octets. The value of this field is always
1 for G.9959 NodeIDs.</t>
<t>NodeID: This is the G.9959 NodeID the actual interface currently
responds to. The link-layer address may change if the interface joins
another network at a later time.</t>
</section>
<section title="On the use of Neighbor Discovery technologies">
<t><xref target="RFC4861"/> specifies how IPv6 nodes may resolve link
layer addresses from IPv6 addresses via the use of link-local IPv6
multicast. <xref target="RFC6775"/> is an optimization of <xref
target="RFC4861"/>, specifically targeting 6LoWPAN networks. <xref
target="RFC6775"/> defines how a 6LoWPAN node may register IPv6
addresses with an authoritative border router (ABR). Mesh-under
networks MUST NOT use <xref target="RFC6775"/> address registration.
However, <xref target="RFC6775"/> address registration MUST be used if
the first 6 bytes of the IID do not comply with the format defined in
Figure 3.</t>
<section title="Prefix and CID management (Route-over)">
<t>In route-over environments, IPv6 hosts MUST use <xref
target="RFC6775"/> address registration. A node implementation for
route-over operation MAY use RFC6775 mechanisms for obtaining IPv6
prefixes and corresponding header compression context information
<xref target="RFC6282"/>. RFC6775 Route-over requirements apply with
no modifications.</t>
</section>
<section title="Prefix and CID management (Mesh-under)">
<t>An implementation for mesh-under operation MUST use <xref
target="RFC6775"/> mechanisms for managing IPv6 prefixes and
corresponding header compression context information <xref
target="RFC6282"/>. <xref target="RFC6775"/> Duplicate Address
Detection (DAD) MUST NOT be used, since the link-layer inclusion
process of G.9959 ensures that a NodeID is unique for a given
HomeID.</t>
<t>With this exception and the specific redefinition of the RA
Router Lifetime value 0xFFFF (refer to <xref
target="Section_InfinitePrefixLifetimeSupport"/>), the text of the
following subsections is in compliance with <xref
target="RFC6775"/>.</t>
<section title="Prefix assignment considerations">
<t>As stated by <xref target="RFC6775"/>, an ABR is responsible
for managing prefix(es). Global routable prefixes may change over
time. It is RECOMMENDED that a ULA prefix is assigned to the
6LoWPAN subnet to facilitate stable site-local application
associations based on IPv6 addresses. A node MAY support the M
flag of the RA message. This influences the way IPv6 addresses are
assigned. Refer to <xref target="ChapterG9959_AddressingMode"/>
for details.</t>
</section>
<section title="Robust and efficient CID management">
<t>The 6LoWPAN Context Option (6CO) is used according to <xref
target="RFC6775"/> in an RA to disseminate Context IDs (CID) to
use for compressing prefixes. One or more prefixes and
corresponding Context IDs MUST be assigned during initial node
inclusion.</t>
<t>When updating context information, a CID may have its lifetime
set to zero to obsolete it. The CID MUST NOT be reused
immediately; rather the next vacant CID should be assigned. Header
compression based on CIDs MUST NOT be used for RA messages
carrying Context Information. An expired CID and the associated
prefix MUST NOT be reset but rather retained in receive-only mode
if there is no other current need for the CID value. This will
allow an ABR to detect if a sleeping node without clock uses an
expired CID and in response, the ABR MUST return an RA with fresh
Context Information to the originator.</t>
</section>
<section anchor="Section_InfinitePrefixLifetimeSupport"
title="Infinite prefix lifetime support for island-mode networks">
<t>Nodes MUST renew the prefix and CID according to the lifetime
signaled by the ABR. <xref target="RFC6775"/> specifies that the
maximum value of the RA Router Lifetime field MAY be up to 0xFFFF.
This document further specifies that the value 0xFFFF MUST be
interpreted as infinite lifetime. This value MUST NOT be used by
ABRs. Its use is only intended for a sleeping network controller;
for instance a battery powered remote control being master for a
small island-mode network of light modules.</t>
</section>
</section>
</section>
</section>
<section anchor="HeaderCompression" title="Header Compression">
<t>IPv6 header compression <xref target="RFC6282"/> MUST be implemented
and <xref target="RFC_TBD_GHC"/> compression for higher layers MAY be
implemented. This section will simply identify substitutions that should
be made when interpreting the text of <xref target="RFC6282"/> and <xref
target="RFC_TBD_GHC"/>.</t>
<t>In general the following substitutions should be made:</t>
<t><list style="symbols">
<t>Replace "802.15.4" with "G.9959"</t>
<t>Replace "802.15.4 short address" with
"<Interface><G.9959 NodeID>"</t>
<t>Replace "802.15.4 PAN ID" with "G.9959 HomeID"</t>
</list>When a 16-bit address is called for (i.e., an IEEE 802.15.4
"short address") it MUST be formed by prepending an Interface label byte
to the G.9959 NodeID:</t>
<figure>
<artwork><![CDATA[ 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><vspace blankLines="1"/>A transmitting node may be sending to an IPv6
destination address which can be reconstructed from the link-layer
destination address. If the Interface number is zero (the default
value), all IPv6 address bytes may be elided. Likewise, the Interface
number of a fully elided IPv6 address (i.e. SAM/DAM=11) may be
reconstructed to the value zero by a receiving node.</t>
<t>64 bit 802.15.4 address details do not apply.</t>
</section>
<section anchor="IANA_Considerations" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The method of derivation of Interface Identifiers from 8-bit NodeIDs
preserves uniqueness within the network. However, there is no protection
from duplication through forgery. Neighbor Discovery in G.9959 links may
be susceptible to threats as detailed in <xref target="RFC3756"/>.
G.9959 networks may feature mesh routing. This implies additional
threats due to ad hoc routing as per <xref target="KW03"/>. G.9959
provides capability for link-layer security. G.9959 nodes MUST use
link-layer security with a shared key. Doing so will alleviate the
majority of threats stated above. A sizeable portion of G.9959 devices
is expected to always communicate within their PAN (i.e., within their
subnet, in IPv6 terms). In response to cost and power consumption
considerations, these devices will typically implement the minimum set
of features necessary. Accordingly, security for such devices may rely
on the mechanisms defined at the link layer by G.9959. G.9959 relies on
the Advanced Encryption Standard (AES) for authentication and encryption
of G.9959 frames and further employs challenge-response handshaking to
prevent replay attacks.</t>
<t>It is also expected that some G.9959 devices (e.g. billing and/or
safety critical products) will implement coordination or integration
functions. These may communicate regularly with IPv6 peers outside the
subnet. Such IPv6 devices are expected to secure their end-to-end
communications with standard security mechanisms (e.g., IPsec, TLS,
etc).</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>IP addresses may be used to track devices on the Internet, which in
turn can be linked to individuals and their activities. Depending on the
application and the actual use pattern, this may be undesirable. To
impede tracking, globally unique and non-changing characteristics of IP
addresses should be avoided, e.g. by frequently changing the global
prefix and avoiding unique link-layer-derived IIDs in addresses.</t>
<t>Some link layers use a 48-bit or a 64-bit link layer address which
uniquely identifies the node on a global scale regardless of global
prefix changes. The risk of exposing a G.9959 device from its
link-layer-derived IID is limited because of the short 8-bit link layer
address.</t>
<t>While intended for central address management, DHCPv6 address
assignment also decouples the IPv6 address from the link layer address.
Addresses may be made dynamic by the use of a short DHCP lease period
and an assignment policy which makes the DHCP server hand out a fresh IP
address every time.</t>
<t>It should be noted that privacy and frequently changing address
assignment comes at a cost. Non-link-layer-derived IIDs require the use
of address registration and further, non-link-layer-derived IIDs cannot
be compressed, which leads to longer datagrams and increased link layer
segmentation. Finally, frequent prefix changes necessitate more Context
Identifier updates, which not only leads to increased traffic but also
may affect the battery lifetime of sleeping nodes.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to the authors of RFC 4944 and RFC 6282 and members of the
IETF 6LoWPAN working group; this document borrows extensively from their
work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn, Michael
Richardson, Tommas Jess Christensen for useful comments. Thanks to
Carsten Bormann for extensive feedback which improved this document
significantly. Thanks to Brian Haberman for pointing out unclear
details.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4291"?>
<?rfc include="reference.RFC.4944"?>
<?rfc include="reference.RFC.6282"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.4861"?>
<?rfc include="reference.RFC.4193"?>
<?rfc include="reference.RFC.6775"?>
<reference anchor="RFC_TBD_GHC">
<front>
<title>draft-ietf-6lo-ghc: 6LoWPAN Generic Compression of Headers
and Header-like Payloads</title>
<author fullname=""/>
<date day="8" month="September" year="2014"/>
</front>
</reference>
<reference anchor="G.9959">
<front>
<title>G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range,
narrow-band digital radiocommunication transceivers</title>
<author fullname=""/>
<date day="1" month="February" year="2012"/>
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="EUI64">
<front>
<title>GUIIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
REGISTRATION AUTHORITY</title>
<author fullname="">
<organization>IEEE</organization>
</author>
<date day="1" month="November" year="2012"/>
</front>
<seriesInfo name="IEEE Std"
value="http:// standards.ieee.org/regauth/oui/tutorials/EUI64.html"/>
</reference>
<reference anchor="KW03">
<front>
<title>"Secure Routing in Sensor Networks: Attacks and
Countermeasures", Special Issue on Sensor Network Applications and
Protocols vol 1, issues 2-3</title>
<author fullname="Karlof, Chris and Wagner, David">
<organization>Elsevier's AdHoc Networks Journal</organization>
</author>
<date day="1" month="September" year="2003"/>
</front>
<seriesInfo name="" value=""/>
</reference>
<?rfc include="reference.RFC.3315"?>
<?rfc include="reference.RFC.3587"?>
<?rfc include="reference.RFC.3819"?>
<?rfc include="reference.RFC.3756"?>
<?rfc include="reference.RFC.6550"?>
<?rfc include="reference.RFC.6997"?>
</references>
<section anchor="appendix_datagram_example"
title="G.9959 6LoWPAN datagram example">
<t>This example outlines each individual bit of a sample IPv6 UDP packet
arriving to a G.9959 node from a host in the Internet via a PAN border
router.</t>
<t>In the G.9959 PAN, the complete frame has the following fields.</t>
<figure>
<artwork><![CDATA[
G.9959:
+------+---------+----------+---+-----+----------...
|HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID|
+------+---------+----------+---+-----+----------+-...
6LoWPAN:
...+--------------+----------------+-----------------------...
|6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers|
...-------------+----------------+-----------------------+-...
6LoWPAN, TCP/UDP, App payload:
...+-------------------------+------------+-----------+
|Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload|
...------------------------+------------+-----------+
]]></artwork>
</figure>
<t>The frame comes from the source IPv6 address
2001:0db8:ac10:ef01::ff:fe00:1206. The source prefix
2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3.</t>
<t>The frame is delivered in direct range from the gateway which has
source NodeID = 1. The Interface Identifier (IID) ff:fe00:1206 is
recognised as a link-layer-derived address and is compressed to the 16
bit value 0x1206.</t>
<t>The frame is sent to the destination IPv6 address
2001:0db8:27ef:42ca::ff:fe00:0004. The destination prefix
2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2.</t>
<t>The Interface Identifier (IID) ff:fe00:0004 is recognised as a
link-layer-derived address.</t>
<t>Thanks to the link-layer-derived addressing rules, the sender knows
that this is to be sent to G.9959 NodeID = 4; targeting the IPv6
interface instance number 0 (the default).</t>
<t>To reach the 6LoWPAN stack of the G.9959 node, (skipping the G.9959
header fields) the first octet must be the 6LoWPAN Command Class
(0x4F).</t>
<figure>
<artwork><![CDATA[ 0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-...
| 0x4F |
+-+-+-+-+-+-+-+-+-...
The Dispatch header bits '011' advertises a compressed IPv6 header.
0 1
0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1
+-+-+-+-+-+-+-+-+-+-+-+-...
The following bits encode the first IPv6 header fields:
TF = '11' : Traffic Class and Flow Label are elided.
NH = '1' : Next Header is elided
HLIM = '10' : Hop limit is 64
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
]]></artwork>
</figure>
<t/>
<figure>
<artwork><![CDATA[CID = '1' : CI data follows the DAM field
SAC = '1' : Src addr uses stateful, context-based compression
SAM = '10' : Use src CID and 16 bits for link-layer-derived addr
M = '0' : Dest addr is not a multicast addr
DAC = '1' : Dest addr uses stateful, context-based compression
DAM = '11' : Use dest CID and dest NodeID to link-layer-derived addr
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 1 0|1 1 1 0 0 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
]]></artwork>
</figure>
<t/>
<figure>
<artwork><![CDATA[Address compression context identifiers:
SCI = 0x3
DCI = 0x2
2 3
4 5 6 7 8 9 0 1
...+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 |
...+-+-+-+-+-+-+-+-...
]]></artwork>
</figure>
<t/>
<figure>
<artwork><![CDATA[IPv6 header fields:
(skipping "version" field)
(skipping "Traffic Class")
(skipping "flow label")
(skipping "payload length")
IPv6 header address fields:
SrcIP = 0x1206 : Use SCI and 16 LS bits of link-layer-derived address
(skipping DestIP ) - completely reconstructed from Dest NodeID and DCI
2 3 4
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 | 0x12 | 0x06 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
]]></artwork>
</figure>
<t/>
<figure>
<artwork><![CDATA[Next header encoding for the UDP header:
Dispatch = '11110': Next Header dispatch code for UDP header
C = '0' : 16 bit checksum carried inline
P = '00' : Both src port and dest Port are carried in-line.
4 5
8 9 0 1 2 3 4 5
...+-+-+-+-+-+-+-+-...
|1 1 1 1 0|0|0 0|
...+-+-+-+-+-+-+-+-...
]]></artwork>
</figure>
<t/>
<figure>
<artwork><![CDATA[UDP header fields:
src Port = 0x1234
dest port = 0x5678
5 6 7 8
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 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x12 | 0x34 | 0x56 | 0x78 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..
(skipping "length")
checksum = .... (actual checksum value depends on
the actual UDP payload)
1
8 9 0
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| (UDP checksum) |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Add your own UDP payload here...
]]></artwork>
</figure>
<t/>
</section>
<section title="Change Log">
<t/>
<section title="Changes since -00">
<t><list style="symbols">
<t>Clarified that mesh-under routing may take place below the
6LoWPAN layer but that specific mesh-under routing protocols are
not within the scope of this doc.</t>
<t>Clarified that RFC6282 IPv6 Header Compression MUST be
supported.</t>
<t>Clarified the text of section 5.4 on the use of RFC6775 address
registration in mesh-under networks.</t>
<t>Split 5.4.2 into multiple paragraphs.</t>
</list></t>
</section>
<section title="Changes since -01">
<t><list style="symbols">
<t>Added this Change Log</t>
<t>Editorial nits.</t>
<t>Made IPv6 Header Compression mandatory. Therefore, the Dispatch
value "01 000001 - Uncompressed IPv6 Addresses" was removed from
figure 2.</t>
<t>Changed SHOULD to MUST: An IPv6 host SHOULD construct its
link-local IPv6 address and routable IPv6 addresses from the
NodeID in order to facilitate IP header compression as described
in [RFC6282].</t>
<t>Changed SHOULD NOT to MUST NOT: Mesh-under networks MUST NOT
use [RFC6775] address registration.</t>
<t>Changed SHOULD NOT to MUST NOT: [RFC6775] Duplicate Address
Detection (DAD) MUST NOT be used.</t>
<t>Changed SHOULD NOT to MUST NOT: The CID MUST NOT be reused
immediately;</t>
<t>Changed SHOULD NOT to MUST NOT: An expired CID and the
associated prefix MUST NOT be reset but rather retained in
receive-only mode</t>
<t>Changed LBR -> ABR</t>
<t>Changed SHOULD to MUST: , the ABR MUST return an RA with fresh
Context Information to the originator.</t>
<t>Changed SHOULD NOT to MUST NOT: This value MUST NOT be used by
ABRs. Its use is only intended for a sleeping network
controller.</t>
</list></t>
</section>
<section title="Changes since -02">
<t><list style="symbols">
<t>Editorial nits.</t>
<t>Moved text to the right section so that it does not prohibit
DAD for Route-Over deployments.</t>
<t>Introduced RA M flag support so that nodes may be instructed to
use DHCPv6 for centralized address assignment.</t>
<t>Added example appendix: Complete G.9959 6LoWPAN datagram
composition with CID-based header compression.</t>
</list></t>
</section>
<section title="Changes since -03">
<t><list style="symbols">
<t>Corrected error in 6LoWPAN datagram example appendix: 64 hop
limit in comment => also 64 hop limit in actual frame
format.</t>
<t>Added section "Privacy Considerations"</t>
</list></t>
</section>
<section title="Changes since -04">
<t><list style="symbols">
<t>Text on RA M flag support was replaced with a table to improve
clarity.</t>
<t>Added further details to text on achieving privacy addressing
with DHCP.</t>
</list></t>
</section>
<section title="Changes since -05">
<t><list style="symbols">
<t>Term ABR now points to Authoritative 6LBR as defined by
RFC6775.</t>
<t>Removed sentence "The G.9959 network controller function SHOULD
be integrated in the ABR." as this was an implementation guideline
with no relevance to network performance.</t>
<t>Clarifying that network controller function redundancy is
relevant for network deployers; not user-level application
designers.</t>
<t>Clarified that RFC2460 specifies that link layer must provide
fragmentation if 1280 octet packets cannot be carried in one piece
by the link layer.</t>
<t>Clarified that the 6LoWPAN CmdCls identifier value is assigned
by the ITU-T.</t>
<t>Added reference to Privacy Considerations section from 6LoWPAN
Addressing section.</t>
<t>Introducing optional GHC header compression.</t>
</list></t>
</section>
<section title="Changes since -06">
<t><list style="symbols">
<t>Added a note to section 5, that the mapping of 802.15.4 terms
to similar G.9959 terms applies not only to RFC6282 but also to
GHC.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:32:55 |