draft-ietf-6lo-lowpanz-08.txt   rfc7428.txt 
IPv6 over Networks of Resource-constrained Nodes (6lo) WG A. Brandt Internet Engineering Task Force (IETF) A. Brandt
Internet-Draft J. Buron Request for Comments: 7428 J. Buron
Intended status: Standards Track Sigma Designs Category: Standards Track Sigma Designs
Expires: May 3, 2015 October 30, 2014 ISSN: 2070-1721 February 2015
Transmission of IPv6 packets over ITU-T G.9959 Networks Transmission of IPv6 Packets over ITU-T G.9959 Networks
draft-ietf-6lo-lowpanz-08
Abstract Abstract
This document describes the frame format for transmission of IPv6 This document describes the frame format for transmission of IPv6
packets and a method of forming IPv6 link-local addresses and packets as well as a method of forming IPv6 link-local addresses and
statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks. statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.
Requirements Language
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 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on May 3, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7428.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Terms used . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terms Used .................................................3
2. G.9959 parameters to use for IPv6 transport . . . . . . . . . 5 1.2. Requirements Language ......................................4
2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 5 2. G.9959 Parameters to Use for IPv6 Transport .....................5
2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 6 2.1. Addressing Mode ............................................5
2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 6 2.2. IPv6 Multicast Support .....................................6
2.4. Transmission status indications . . . . . . . . . . . . . 7 2.3. G.9959 MAC PDU Size and IPv6 MTU ...........................6
2.5. Transmission security . . . . . . . . . . . . . . . . . . 7 2.4. Transmission Status Indications ............................7
3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 7 2.5. Transmission Security ......................................7
3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 8 3. 6LoWPAN Adaptation Layer and Frame Format .......................7
4. 6LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . 9 3.1. Dispatch Header ............................................8
4.1. Stateless Address Autoconfiguration of routable IPv6 4. 6LoWPAN Addressing ..............................................9
addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Stateless Address Autoconfiguration of Routable IPv6
4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9 Addresses ..................................................9
4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 10 4.2. IPv6 Link-Local Address ...................................10
4.4. On the use of Neighbor Discovery technologies . . . . . . 10 4.3. Unicast Address Mapping ...................................10
4.4.1. Prefix and CID management (Route-over) . . . . . . . 11 4.4. On the Use of Neighbor Discovery Technologies .............11
4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 11 4.4.1. Prefix and CID Management (Route-Over) .............11
5. Header Compression . . . . . . . . . . . . . . . . . . . . . 12 4.4.2. Prefix and CID Management (Mesh-Under) .............11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Header Compression .............................................12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations ........................................13
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 7. Privacy Considerations .........................................14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. References .....................................................14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References ......................................14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References ....................................16
10.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. G.9959 6LoWPAN Datagram Example .......................17
Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 16 Acknowledgements ..................................................21
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses ................................................21
B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 20
B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 20
B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 21
B.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 21
B.5. Changes since -04 . . . . . . . . . . . . . . . . . . . . 22
B.6. Changes since -05 . . . . . . . . . . . . . . . . . . . . 22
B.7. Changes since -06 . . . . . . . . . . . . . . . . . . . . 22
B.8. Changes since -07 . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The ITU-T G.9959 recommendation [G.9959] targets low-power Personal The ITU-T G.9959 recommendation [G.9959] targets low-power Personal
Area Networks (PANs). This document defines the frame format for Area Networks (PANs). This document defines the frame format for
transmission of IPv6 [RFC2460] packets as well as the formation of transmission of IPv6 [RFC2460] packets as well as the formation of
IPv6 link-local addresses and statelessly autoconfigured IPv6 IPv6 link-local addresses and statelessly autoconfigured IPv6
addresses on G.9959 networks. addresses on G.9959 networks.
The general approach is to adapt elements of [RFC4944] to G.9959 The general approach is to adapt elements of [RFC4944] to G.9959
networks. G.9959 provides a Segmentation and Reassembly (SAR) layer networks. G.9959 provides a Segmentation and Reassembly (SAR) layer
for transmission of datagrams larger than the G.9959 MAC PDU. for transmission of datagrams larger than the G.9959 Media Access
Control Protocol Data Unit (MAC PDU).
[RFC6775] updates [RFC4944] by specifying 6LoWPAN optimizations for [RFC6775] updates [RFC4944] by specifying IPv6 over Low-Power
IPv6 Neighbor Discovery (ND) (originally defined by [RFC4861]). This Wireless Personal Area Network (6LoWPAN) optimizations for IPv6
Neighbor Discovery (ND) (originally defined by [RFC4861]). This
document limits the use of [RFC6775] to prefix and Context ID document limits the use of [RFC6775] to prefix and Context ID
assignment. An IID may be constructed from a G.9959 link-layer assignment. An Interface Identifier (IID) may be constructed from a
address, leading to a "link-layer-derived IPv6 address". If using G.9959 link-layer address, leading to a "link-layer-derived IPv6
that method, Duplicate Address Detection (DAD) is not needed. address". If using that method, Duplicate Address Detection (DAD) is
Alternatively, IPv6 addresses may be assigned centrally via DHCP, not needed. Alternatively, IPv6 addresses may be assigned centrally
leading to a "non-link-layer-derived IPv6 address". Address via DHCP, leading to a "non-link-layer-derived IPv6 address".
registration is only needed in certain cases. Address registration is only needed in certain cases.
In addition to IPv6 application communication, the frame format In addition to IPv6 application communication, the frame format
defined in this document may be used by IPv6 routing protocols such defined in this document may be used by IPv6 routing protocols such
as RPL [RFC6550] or P2P-RPL [RFC6997] to implement IPv6 routing over as the Routing Protocol for Low-Power and Lossy Networks (RPL)
[RFC6550] or Reactive Discovery of Point-to-Point Routes in Low-Power
and Lossy Networks (P2P-RPL) [RFC6997] to implement IPv6 routing over
G.9959 networks. G.9959 networks.
The encapsulation frame defined by this specification may optionally The encapsulation frame defined by this specification may optionally
be transported via mesh routing below the 6LoWPAN layer. Mesh-under be transported via mesh routing below the 6LoWPAN layer. Mesh-under
and route-over routing protocol specifications are out of scope of and route-over routing protocol specifications are out of scope for
this document. this document.
1.1. Terms used 1.1. Terms Used
6LoWPAN: IPv6-based Low-power Personal Area Network 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
ABR: Authoritative 6LBR ([RFC6775]) ABR: Authoritative 6LoWPAN Border Router (Authoritative 6LBR)
[RFC6775]
Ack: Acknowedgement Ack: Acknowledgement
AES: Advanced Encryption Scheme AES: Advanced Encryption Standard
CID: Context Identifier ([RFC6775]) CID: Context Identifier [RFC6775]
DAD: Duplicate Address Detection ([RFC6775]) DAD: Duplicate Address Detection [RFC6775]
DHCPv6: Dynamic Host Configuration Protocol for IPv6 ([RFC3315]) DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315]
EUI-64: Extended Unique Identifier ([EUI64])
G.9959: Short range, narrow-band digital radiocommunication EUI-64: Extended Unique Identifier [EUI64]
transceiver ([G.9959])
GHC: Generic Header Compression ([RFC_TBD_GHC]) G.9959: Short range narrow-band digital radiocommunication
transceiver [G.9959]
HomeID: G.9959 Link-Layer Network Identifier GHC: Generic Header Compression [RFC7400]
IID: Interface IDentifier HomeID: G.9959 Link-Layer Network Identifier
Link-layer-derived address: IPv6 Address constructed on basis of link IID: Interface Identifier
layer address information Link-layer-derived address: IPv6 address constructed on the basis of
link-layer address information
MAC: Media Access Control MAC: Media Access Control
Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer
MTU: Maximum Transmission Unit MTU: Maximum Transmission Unit
ND: Neighbor discovery ([RFC4861], [RFC6775]) ND: Neighbor Discovery [RFC4861] [RFC6775]
NodeID: G.9959 Link-Layer Node Identifier NodeID: G.9959 Link-Layer Node Identifier
Non-link-layer-derived address: IPv6 Address assigned by a managed Non-link-layer-derived address: IPv6 address assigned by a managed
process, e.g. DHCPv6. process, e.g., DHCPv6
NVM: Non-volatile Memory
P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and
Lossy Networks ([RFC6997]) Lossy Networks [RFC6997]
PAN: Personal Area Network PAN: Personal Area Network
PDU: Protocol Data Unit PDU: Protocol Data Unit
PHY: Physical Layer PHY: Physical Layer
RA: Router Advertisement ([RFC4861], [RFC6775]) RA: Router Advertisement [RFC4861] [RFC6775]
Route-over: Forwarding via IP routing above the 6LoWPAN layer Route-over: Forwarding via IP routing above the 6LoWPAN layer
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [RFC6550]
([RFC6550])
SAR: G.9959 Segmentation And Reassembly SAR: G.9959 Segmentation and Reassembly
ULA: Unique Local Address [RFC4193] ULA: Unique Local Address [RFC4193]
2. G.9959 parameters to use for IPv6 transport 1.2. Requirements Language
This chapter outlines properties applying to the PHY and MAC of The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
G.9959 and how to use these for IPv6 transport. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Addressing mode 2. G.9959 Parameters to Use for IPv6 Transport
This section outlines properties applying to the PHY and MAC layers
of G.9959 and how to use these for IPv6 transport.
2.1. Addressing Mode
G.9959 defines how a unique 32-bit HomeID network identifier is G.9959 defines how a unique 32-bit HomeID network identifier is
assigned by a network controller and how an 8-bit NodeID host assigned by a network controller and how an 8-bit NodeID host
identifier is allocated to each node. NodeIDs are unique within the identifier is allocated to each node. NodeIDs are unique within the
network identified by the HomeID. The G.9959 HomeID represents an network identified by the HomeID. The G.9959 HomeID represents an
IPv6 subnet which is identified by one or more IPv6 prefixes. IPv6 subnet that is identified by one or more IPv6 prefixes.
An IPv6 host MUST construct its link-local IPv6 address from the An IPv6 host MUST construct its link-local IPv6 address from the
link-layer-derived IID in order to facilitate IP header compression link-layer-derived IID in order to facilitate IP header compression
as described in [RFC6282]. as described in [RFC6282].
A node interface MAY support the M flag of the RA message for the A node interface MAY support the M flag of the RA message for the
construction of routable IPv6 addresses. A cost optimized node construction of routable IPv6 addresses. A cost-optimized node
implementation may save memory by skipping support for the M flag. implementation may save memory by skipping support for the M flag.
The M flag MUST be interpreted as defined in Figure 1. The M flag MUST be interpreted as defined in Figure 1.
+--------+--------+---------------------------------------------+ +--------+--------+---------------------------------------------+
| M Flag | M flag | Required node behavior | | M flag | M flag | Required node behavior |
| support| value | | | support| value | |
+--------+--------+---------------------------------------------+ +--------+--------+---------------------------------------------+
| No |(ignore)| Node MUST use link-layer-derived addressing | | No |(ignore)| Node MUST use link-layer-derived addressing |
+--------+--------+---------------------------------------------+ +--------+--------+---------------------------------------------+
| Yes | 0 | Node MUST use link-layer-derived addressing | | Yes | 0 | Node MUST use link-layer-derived addressing |
| +--------+---------------------------------------------+ | +--------+---------------------------------------------+
| | 1 | Node MUST use DHCPv6 based addressing and | | | 1 | Node MUST use DHCPv6-based addressing, and |
| | | Node MUST comply fully with [RFC6775] | | | | node MUST comply fully with [RFC6775] |
+--------+--------+---------------------------------------------+ +--------+--------+---------------------------------------------+
Figure 1: RA M flag support and interpretation Figure 1: RA M Flag Support and Interpretation
A node that uses DHCPv6 based addressing MUST comply fully with the A node that uses DHCPv6-based addressing MUST comply fully with the
text of [RFC6775]. text of [RFC6775].
If DHCPv6 based addressing is used, the DHCPv6 client must use a DUID If DHCPv6-based addressing is used, the DHCPv6 client must use a
of type DUID-UUID, as described in [RFC6355]. The UUID used in the DHCPv6 Unique Identifier (DUID) of type DUID-UUID, as described in
DUID-UUID must be generated as specified in [RFC4122], section 4.5, [RFC6355]. The Universally Unique Identifier (UUID) used in the
starting at the second paragraph in that section (the 47-bit random DUID-UUID must be generated as specified in [RFC4122], Section 4.5,
starting at the third paragraph in that section (the 47-bit random
number-based UUID). The DUID must be stored persistently by the node number-based UUID). The DUID must be stored persistently by the node
as specified in section 3 of [RFC6355]. as specified in Section 3 of [RFC6355].
A word of caution: since HomeIDs and NodeIDs are handed out by a A word of caution: since HomeIDs and NodeIDs are handed out by a
network controller function during inclusion, identifier validity and network controller function during inclusion, identifier validity and
uniqueness is limited by the lifetime of the network membership. uniqueness are limited by the lifetime of the network membership.
This can be cut short by a mishap occurring to the network This can be cut short by a mishap occurring at the network
controller. Having a single point of failure at the network controller. Having a single point of failure at the network
controller suggests that high-reliability network deployments may controller suggests that high-reliability network deployments may
benefit from a redundant network controller function. benefit from a redundant network controller function.
This warning applies to link-layer-derived addressing as well as to This warning applies to link-layer-derived addressing as well as to
non-link-layer-derived addressing deployments. non-link-layer-derived addressing deployments.
2.2. IPv6 Multicast support 2.2. IPv6 Multicast Support
[RFC3819] recommends that IP subnetworks support (subnet-wide) [RFC3819] recommends that IP subnetworks support (subnet-wide)
multicast. G.9959 supports direct-range IPv6 multicast while subnet- multicast. G.9959 supports direct-range IPv6 multicast, while
wide multicast is not supported natively by G.9959. Subnet-wide subnet-wide multicast is not supported natively by G.9959. Subnet-
multicast may be provided by an IP routing protocol or a mesh routing wide multicast may be provided by an IP routing protocol or a mesh
protocol operating below the 6LoWPAN layer. Routing protocol routing protocol operating below the 6LoWPAN layer. Routing protocol
specifications are out of scope of this document. specifications are out of scope for this document.
IPv6 multicast packets MUST be carried via G.9959 broadcast. IPv6 multicast packets MUST be carried via G.9959 broadcast.
As per [G.9959], this is accomplished as follows: As per [G.9959], this is accomplished as follows:
1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID 1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID
of the network of the network.
2. The destination NodeID of the G.9959 MAC PDU MUST be the 2. The destination NodeID of the G.9959 MAC PDU MUST be the
broadcast NodeID (0xff) broadcast NodeID (0xff).
G.9959 broadcast MAC PDUs are only intercepted by nodes within the G.9959 broadcast MAC PDUs are only intercepted by nodes within the
network identified by the HomeID. network identified by the HomeID.
2.3. G.9959 MAC PDU size and IPv6 MTU 2.3. G.9959 MAC PDU Size and IPv6 MTU
IPv6 packets MUST be transmitted using G.9959 transmission profile R3 IPv6 packets MUST be transmitted using G.9959 transmission profile R3
or higher. or higher.
[RFC2460] specifies that any link that cannot convey a 1280-octet [RFC2460] specifies that any link that cannot convey a 1280-octet
packet in one piece, must provide link-specific fragmentation and packet in one piece must provide link-specific fragmentation and
reassembly at a layer below IPv6. reassembly at a layer below IPv6.
G.9959 provides Segmentation And Reassembly for payloads up to 1350 G.9959 provides segmentation and reassembly for payloads up to
octets. IPv6 Header Compression [RFC6282] improves the chances that 1350 octets. IPv6 header compression [RFC6282] improves the chances
a short IPv6 packet can fit into a single G.9959 frame. Therefore, that a short IPv6 packet can fit into a single G.9959 frame.
Section 3 specifies that [RFC6282] MUST be supported. With the Therefore, Section 3 of this document specifies that [RFC6282] MUST
mandatory link-layer security enabled, a G.9959 R3 MAC PDU may be supported. With the mandatory link-layer security enabled, a
accommodate 6LoWPAN datagrams of up to 130 octets without triggering G.9959 R3 MAC PDU may accommodate 6LoWPAN datagrams of up to
G.9959 Segmentation and Reassembly (SAR). Longer 6LoWPAN datagrams 130 octets without triggering G.9959 segmentation and reassembly.
will lead to the transmission of multiple G.9959 PDUs. Longer 6LoWPAN datagrams will lead to the transmission of multiple
G.9959 PDUs.
2.4. Transmission status indications 2.4. Transmission Status Indications
The G.9959 MAC layer provides native acknowledgement and The G.9959 MAC layer provides native acknowledgement and
retransmission of MAC PDUs. The G.9959 SAR layer does the same for retransmission of MAC PDUs. The G.9959 SAR layer does the same for
larger datagrams. A mesh routing layer may provide a similar feature larger datagrams. A mesh routing layer may provide a similar feature
for routed communication. An IPv6 routing stack communicating over for routed communication. An IPv6 routing stack communicating over
G.9959 may utilize link-layer status indications such as delivery G.9959 may utilize link-layer status indications such as delivery
confirmation and Ack timeout from the MAC layer. confirmation and Ack timeout from the MAC layer.
2.5. Transmission security 2.5. Transmission Security
Implementations claiming conformance with this document MUST enable Implementations claiming conformance with this document MUST enable
G.9959 shared network key security. G.9959 shared network key security.
The shared network key is intended to address security requirements The shared network key is intended to address security requirements
in the home at the normal security requirements level. For in the home at the normal level of security requirements. For
applications with high or very high requirements on confidentiality applications with high or very high requirements for confidentiality
and/or integrity, additional application layer security measures for and/or integrity, additional application-layer security measures for
end-to-end authentication and encryption may need to be applied. end-to-end authentication and encryption may need to be applied.
(The availability of the network relies on the security properties of (The availability of the network relies on the security properties of
the network key in any case) the network key in any case.)
3. 6LoWPAN Adaptation Layer and Frame Format 3. 6LoWPAN Adaptation Layer and Frame Format
The 6LoWPAN encapsulation formats defined in this chapter are carried The 6LoWPAN encapsulation formats defined in this section are carried
as payload in the G.9959 MAC PDU. IPv6 header compression [RFC6282] as payload in the G.9959 MAC PDU. IPv6 header compression [RFC6282]
MUST be supported by implementations of this specification. Further, MUST be supported by implementations of this specification. Further,
implementations MAY support Generic Header Compression (GHC) implementations MAY support Generic Header Compression (GHC)
[RFC_TBD_GHC]. A node implementing [RFC_TBD_GHC] MUST probe its [RFC7400]. A node implementing [RFC7400] MUST probe its peers for
peers for GHC support before applying GHC compression. GHC support before applying GHC.
All 6LoWPAN datagrams transported over G.9959 are prefixed by a All 6LoWPAN datagrams transported over G.9959 are prefixed by a
6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this 6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this
encapsulation header stack. Each header in the header stack contains encapsulation header stack. Each header in the header stack contains
a header type followed by zero or more header fields. An IPv6 header a header type followed by zero or more header fields. An IPv6 header
stack may contain, in the following order, addressing, hop-by-hop stack may contain, in the following order, addressing, hop-by-hop
options, routing, fragmentation, destination options, and finally options, routing, fragmentation, destination options, and, finally,
payload [RFC2460]. The 6LoWPAN header format is structured the same payload [RFC2460]. The 6LoWPAN header format is structured the same
way. Currently only one payload option is defined for the G.9959 way. Currently, only one payload option is defined for the G.9959
6LoWPAN header format. 6LoWPAN header format.
The definition of 6LoWPAN headers consists of the dispatch value, the The definition of 6LoWPAN headers consists of the dispatch value, the
definition of the header fields that follow, and their ordering definition of the header fields that follow, and their ordering
constraints relative to all other headers. Although the header stack constraints relative to all other headers. Although the header stack
structure provides a mechanism to address future demands on the structure provides a mechanism to address future demands on the
6LoWPAN adaptation layer, it is not intended to provide general 6LoWPAN adaptation layer, it is not intended to provide general-
purpose extensibility. purpose extensibility.
An example of a complete G.9959 6LoWPAN datagram can be found in An example of a complete G.9959 6LoWPAN datagram can be found in
Appendix A. Appendix A.
3.1. Dispatch Header 3.1. Dispatch Header
The dispatch header is shown below: The Dispatch Header is shown below:
0 1 2 3 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 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 | | 6LoWPAN CmdCls| Dispatch | Type-specific header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Dispatch Type and Header Figure 2: Dispatch Type and Header
6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST 6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST
carry the value 0x4F [G.9959]. The value is assigned by the ITU-T carry the value 0x4F [G.9959]. The value is assigned by the ITU-T
and specifies that the following bits are a 6LoWPAN encapsulated and specifies that the following bits are a 6LoWPAN encapsulated
datagram. 6LoWPAN protocols MUST ignore the G.9959 frame if the datagram. 6LoWPAN protocols MUST ignore the G.9959 frame if the
6LoWPAN Command Class identifier deviates from 0x4F. 6LoWPAN Command Class identifier deviates from 0x4F.
Dispatch: Identifies the header type immediately following the Dispatch: Identifies the header type immediately following the
Dispatch Header. Dispatch Header.
Type-specific header: A header determined by the Dispatch Header. Type-specific header: A header determined by the Dispatch Header.
The dispatch value may be treated as an unstructured namespace. Only The dispatch value may be treated as an unstructured namespace. Only
a few symbols are required to represent current 6LoWPAN a few symbols are required to represent current 6LoWPAN
functionality. Although some additional savings could be achieved by functionality. Although some additional savings could be achieved by
encoding additional functionality into the dispatch byte, these encoding additional functionality into the dispatch byte, these
measures would tend to constrain the ability to address future measures would tend to constrain the ability to address future
alternatives. alternatives.
Dispatch values used in this specification are compatible with the +------------+--------------------+-----------+
dispatch values defined by [RFC4944] and [RFC6282]. | Pattern | Header Type | Reference |
+------------+--------------------+-----------+
| 01 1xxxxx | 6LoWPAN_IPHC | [RFC6282] |
+------------+--------------------+-----------+
+------------+------------------------------------------+-----------+ Other IANA-assigned 6LoWPAN dispatch values do not
| Pattern | Header Type | Reference | apply to this document.
+------------+------------------------------------------+-----------+
| 01 1xxxxx | 6LoWPAN_IPHC - Compressed IPv6 Addresses | [RFC6282] |
+------------+------------------------------------------+-----------+
All other Dispatch values are unassigned in this document.
Figure 3: Dispatch values Figure 3: Dispatch Values
6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282]. 6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282].
4. 6LoWPAN addressing 4. 6LoWPAN Addressing
IPv6 addresses may be autoconfigured from IIDs which may again be IPv6 addresses may be autoconfigured from IIDs that may again be
constructed from link-layer address information to save memory in constructed from link-layer address information to save memory in
devices and to facilitate efficient IP header compression as per devices and to facilitate efficient IP header compression as per
[RFC6282]. Link-layer-derived addresses have a static nature and may [RFC6282]. Link-layer-derived addresses have a static nature and may
involuntarily expose private usage data on public networks. Refer to involuntarily expose private usage data on public networks. Refer to
Section 8. Section 7.
A NodeID is mapped into an IEEE EUI-64 identifier as follows: A NodeID is mapped into an IEEE EUI-64 identifier as follows:
IID = 0000:00ff:fe00:YYXX IID = 0000:00ff:fe00:YYXX
Figure 4: Constructing a compressible IID Figure 4: Constructing a Compressible IID
where XX carries the G.9959 NodeID and YY is a one byte value chosen where XX carries the G.9959 NodeID and YY is a 1-byte value chosen by
by the individual node. The default YY value MUST be zero. A node the individual node. The default YY value MUST be zero. A node MAY
MAY use other values of YY than zero to form additional IIDs in order use values of YY other than zero to form additional IIDs in order to
to instantiate multiple IPv6 interfaces. The YY value MUST be instantiate multiple IPv6 interfaces. The YY value MUST be ignored
ignored when computing the corresponding NodeID (the XX value) from when computing the corresponding NodeID (the XX value) from an IID.
an IID.
The method of constructing IIDs from the link-layer address obviously The method of constructing IIDs from the link-layer address obviously
does not support addresses assigned or constructed by other means. A 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 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 Figure 4. In that the IID do not comply with the format defined in Figure 4. In that
case, the address resolution mechanisms of RFC 6775 apply. case, the address resolution mechanisms of [RFC6775] apply.
4.1. Stateless Address Autoconfiguration of routable IPv6 addresses 4.1. Stateless Address Autoconfiguration of Routable IPv6 Addresses
The IID defined above MUST be used whether autoconfiguring a ULA IPv6 The IID defined above MUST be used whether autoconfiguring a ULA IPv6
address [RFC4193] or a globally routable IPv6 address [RFC3587] in address [RFC4193] or a globally routable IPv6 address [RFC3587] in
G.9959 subnets. G.9959 subnets.
4.2. IPv6 Link Local Address 4.2. IPv6 Link-Local Address
The IPv6 link-local address [RFC4291] for a G.9959 interface is The IPv6 link-local address [RFC4291] for a G.9959 interface is
formed by appending the IID defined above to the IPv6 link local formed by appending the IID defined above to the IPv6 link-local
prefix FE80::/64. prefix fe80::/64.
The "Universal/Local" (U/L) bit MUST be set to zero in keeping with The "Universal/Local" (U/L) bit MUST be set to zero in keeping with
the fact that this is not a globally unique value [EUI64]. the fact that this is not a globally unique value [EUI64].
The resulting link local address is formed as follows: The resulting link-local address is formed as follows:
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier (IID) | |1111111010| (zeros) | Interface Identifier (IID) |
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
Figure 5: IPv6 Link Local Address Figure 5: IPv6 Link-Local Address
4.3. Unicast Address Mapping 4.3. Unicast Address Mapping
The address resolution procedure for mapping IPv6 unicast addresses The address resolution procedure for mapping IPv6 unicast addresses
into G.9959 link-layer addresses follows the general description in into G.9959 link-layer addresses follows the general description in
Section 7.2 of [RFC4861]. The Source/Target Link-layer Address Section 7.2 of [RFC4861]. The Source/Target Link-layer Address
option MUST have the following form when the link layer is G.9959. option MUST have the following form when the link layer is G.9959.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 | | Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | NodeID | | 0x00 | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding | | Padding |
+- -+ +- -+
| (All zeros) | | (All zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv6 Unicast Address Mapping Figure 6: IPv6 Unicast Address Mapping
Option fields: Option fields:
Type: The value 1 signifies the Source Link-layer address. The value Type: The value 1 signifies the Source Link-layer address. The
2 signifies the Destination Link-layer address. value 2 signifies the Destination Link-layer address.
Length: This is the length of this option (including the type and 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 Length fields) in units of 8 octets. The value of this field is
always 1 for G.9959 NodeIDs. always 1 for G.9959 NodeIDs.
NodeID: This is the G.9959 NodeID the actual interface currently NodeID: This is the G.9959 NodeID to which the actual interface
responds to. The link-layer address may change if the interface currently responds. The link-layer address may change if the
joins another network at a later time. interface joins another network at a later time.
4.4. On the use of Neighbor Discovery technologies 4.4. On the Use of Neighbor Discovery Technologies
[RFC4861] specifies how IPv6 nodes may resolve link layer addresses [RFC4861] specifies how IPv6 nodes may resolve link-layer addresses
from IPv6 addresses via the use of link-local IPv6 multicast. from IPv6 addresses via the use of link-local IPv6 multicast.
[RFC6775] is an optimization of [RFC4861], specifically targeting [RFC6775] is an optimization of [RFC4861], specifically targeting
6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register 6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register
IPv6 addresses with an authoritative border router (ABR). Mesh-under IPv6 addresses with an authoritative border router (ABR). Mesh-under
networks MUST NOT use [RFC6775] address registration. However, networks MUST NOT use [RFC6775] address registration. However,
[RFC6775] address registration MUST be used if the first 6 bytes of [RFC6775] address registration MUST be used if the first 6 bytes of
the IID do not comply with the format defined in Figure 3. the IID do not comply with the format defined in Figure 4.
4.4.1. Prefix and CID management (Route-over) 4.4.1. Prefix and CID Management (Route-Over)
In route-over environments, IPv6 hosts MUST use [RFC6775] address In route-over environments, IPv6 hosts MUST use [RFC6775] address
registration. A node implementation for route-over operation MAY use registration. A node implementation for route-over operation MAY use
RFC6775 mechanisms for obtaining IPv6 prefixes and corresponding [RFC6775] mechanisms for obtaining IPv6 prefixes and corresponding
header compression context information [RFC6282]. RFC6775 Route-over header compression context information [RFC6282]. [RFC6775] route-
requirements apply with no modifications. over requirements apply with no modifications.
4.4.2. Prefix and CID management (Mesh-under) 4.4.2. Prefix and CID Management (Mesh-Under)
An implementation for mesh-under operation MUST use [RFC6775] An implementation for mesh-under operation MUST use [RFC6775]
mechanisms for managing IPv6 prefixes and corresponding header mechanisms for managing IPv6 prefixes and corresponding header
compression context information [RFC6282]. [RFC6775] Duplicate compression context information [RFC6282]. [RFC6775] Duplicate
Address Detection (DAD) MUST NOT be used, since the link-layer Address Detection (DAD) MUST NOT be used, since the link-layer
inclusion process of G.9959 ensures that a NodeID is unique for a inclusion process of G.9959 ensures that a NodeID is unique for a
given HomeID. given HomeID.
With this exception and the specific redefinition of the RA Router With this exception and the specific redefinition of the RA Router
Lifetime value 0xFFFF (refer to Section 4.4.2.3), the text of the Lifetime value 0xFFFF (refer to Section 4.4.2.3), the text of the
following subsections is in compliance with [RFC6775]. following subsections is in compliance with [RFC6775].
4.4.2.1. Prefix assignment considerations 4.4.2.1. Prefix Assignment Considerations
As stated by [RFC6775], an ABR is responsible for managing As stated by [RFC6775], an ABR is responsible for managing
prefix(es). Global routable prefixes may change over time. It is prefix(es). Global routable prefixes may change over time. It is
RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to
facilitate stable site-local application associations based on IPv6 facilitate stable site-local application associations based on IPv6
addresses. A node MAY support the M flag of the RA message. This addresses. A node MAY support the M flag of the RA message. This
influences the way IPv6 addresses are assigned. Refer to Section 2.1 influences the way IPv6 addresses are assigned. Refer to Section 2.1
for details. for details.
4.4.2.2. Robust and efficient CID management 4.4.2.2. Robust and Efficient CID Management
The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an
RA to disseminate Context IDs (CID) to use for compressing prefixes. RA to disseminate Context IDs (CIDs) to use for compressing prefixes.
One or more prefixes and corresponding Context IDs MUST be assigned One or more prefixes and corresponding Context IDs MUST be assigned
during initial node inclusion. during initial node inclusion.
When updating context information, a CID may have its lifetime set to When updating context information, a CID may have its lifetime set to
zero to obsolete it. The CID MUST NOT be reused immediately; rather zero to obsolete it. The CID MUST NOT be reused immediately; rather,
the next vacant CID should be assigned. Header compression based on the next vacant CID should be assigned. Header compression based on
CIDs MUST NOT be used for RA messages carrying Context Information. CIDs MUST NOT be used for RA messages carrying context information.
An expired CID and the associated prefix MUST NOT be reset but rather 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 must be retained in receive-only mode if there is no other current
the CID value. This will allow an ABR to detect if a sleeping node need for the CID value. This will allow an ABR to detect if a
without clock uses an expired CID and in response, the ABR MUST sleeping node without a clock uses an expired CID, and in response,
return an RA with fresh Context Information to the originator. the ABR MUST return an RA with fresh context information to the
originator.
4.4.2.3. Infinite prefix lifetime support for island-mode networks 4.4.2.3. Infinite Prefix Lifetime Support for Island-Mode Networks
Nodes MUST renew the prefix and CID according to the lifetime Nodes MUST renew the prefix and CID according to the lifetime
signaled by the ABR. [RFC6775] specifies that the maximum value of signaled by the ABR. [RFC6775] specifies that the maximum value of
the RA Router Lifetime field MAY be up to 0xFFFF. This document the RA Router Lifetime field MAY be up to 0xFFFF. This document
further specifies that the value 0xFFFF MUST be interpreted as further specifies that the value 0xFFFF MUST be interpreted as
infinite lifetime. This value MUST NOT be used by ABRs. Its use is infinite lifetime. This value MUST NOT be used by ABRs. Its use is
only intended for a sleeping network controller; for instance a only intended for a sleeping network controller -- for instance, a
battery powered remote control being master for a small island-mode battery-powered remote control being master for a small island-mode
network of light modules. network of light modules.
5. Header Compression 5. Header Compression
IPv6 header compression [RFC6282] MUST be implemented and IPv6 header compression [RFC6282] MUST be implemented, and GHC
[RFC_TBD_GHC] compression for higher layers MAY be implemented. This [RFC7400] compression for higher layers MAY be implemented. This
section will simply identify substitutions that should be made when section will simply identify substitutions that should be made when
interpreting the text of [RFC6282] and [RFC_TBD_GHC]. interpreting the text of [RFC6282] and [RFC7400].
In general the following substitutions should be made: In general, the following substitutions should be made:
o Replace "802.15.4" with "G.9959" o Replace "802.15.4" with "G.9959".
o Replace "802.15.4 short address" with "<Interface><G.9959 NodeID>" o Replace "802.15.4 short address" with "<Interface><G.9959
NodeID>".
o Replace "802.15.4 PAN ID" with "G.9959 HomeID" o Replace "802.15.4 PAN ID" with "G.9959 HomeID".
When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short 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 address"), it MUST be formed by prepending an Interface label byte to
the G.9959 NodeID: the G.9959 NodeID:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface | NodeID | | Interface | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A transmitting node may be sending to an IPv6 destination address A transmitting node may be sending to an IPv6 destination address
which can be reconstructed from the link-layer destination address. that can be reconstructed from the link-layer destination address.
If the Interface number is zero (the default value), all IPv6 address If the Interface number is zero (the default value), all IPv6 address
bytes may be elided. Likewise, the Interface number of a fully bytes may be elided. Likewise, the Interface number of a fully
elided IPv6 address (i.e. SAM/DAM=11) may be reconstructed to the elided IPv6 address (i.e., SAM/DAM=11) may be reconstructed to the
value zero by a receiving node. value zero by a receiving node.
64 bit 802.15.4 address details do not apply. 64-bit 802.15.4 address details do not apply.
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations 6. Security Considerations
The method of derivation of Interface Identifiers from 8-bit NodeIDs The method of derivation of Interface Identifiers from 8-bit NodeIDs
preserves uniqueness within the network. However, there is no preserves uniqueness within the network. However, there is no
protection from duplication through forgery. Neighbor Discovery in protection from duplication through forgery. Neighbor Discovery in
G.9959 links may be susceptible to threats as detailed in [RFC3756]. G.9959 links may be susceptible to threats as detailed in [RFC3756].
G.9959 networks may feature mesh routing. This implies additional G.9959 networks may feature mesh routing. This implies additional
threats due to ad hoc routing as per [KW03]. G.9959 provides threats due to ad hoc routing as per [KW03]. G.9959 provides
capability for link-layer security. G.9959 nodes MUST use link-layer capability for link-layer security. G.9959 nodes MUST use link-layer
security with a shared key. Doing so will alleviate the majority of security with a shared key. Doing so will alleviate the majority of
threats stated above. A sizeable portion of G.9959 devices is threats stated above. A sizable portion of G.9959 devices is
expected to always communicate within their PAN (i.e., within their expected to always communicate within their PAN (i.e., within their
subnet, in IPv6 terms). In response to cost and power consumption subnet, in IPv6 terms). In response to cost and power consumption
considerations, these devices will typically implement the minimum considerations, these devices will typically implement the minimum
set of features necessary. Accordingly, security for such devices set of features necessary. Accordingly, security for such devices
may rely on the mechanisms defined at the link layer by G.9959. may rely on the mechanisms defined at the link layer by G.9959.
G.9959 relies on the Advanced Encryption Standard (AES) for G.9959 relies on the Advanced Encryption Standard (AES) for
authentication and encryption of G.9959 frames and further employs authentication and encryption of G.9959 frames and further employs
challenge-response handshaking to prevent replay attacks. challenge-response handshaking to prevent replay attacks.
It is also expected that some G.9959 devices (e.g. billing and/or It is also expected that some G.9959 devices (e.g., billing and/or
safety critical products) will implement coordination or integration safety-critical products) will implement coordination or integration
functions. These may communicate regularly with IPv6 peers outside functions. These may communicate regularly with IPv6 peers outside
the subnet. Such IPv6 devices are expected to secure their end-to- the subnet. Such IPv6 devices are expected to secure their end-to-
end communications with standard security mechanisms (e.g., IPsec, end communications with standard security mechanisms (e.g., IPsec,
TLS, etc). Transport Layer Security (TLS), etc.).
8. Privacy Considerations 7. Privacy Considerations
IP addresses may be used to track devices on the Internet, which in IP addresses may be used to track devices on the Internet; such
turn can be linked to individuals and their activities. Depending on devices can in turn be linked to individuals and their activities.
the application and the actual use pattern, this may be undesirable. Depending on the application and the actual use pattern, this may be
To impede tracking, globally unique and non-changing characteristics undesirable. To impede tracking, globally unique and non-changing
of IP addresses should be avoided, e.g. by frequently changing the characteristics of IP addresses should be avoided, e.g., by
global prefix and avoiding unique link-layer-derived IIDs in frequently changing the global prefix and avoiding unique link-layer-
addresses. derived IIDs in addresses.
Some link layers use a 48-bit or a 64-bit link layer address which Some link layers use a 48-bit or 64-bit link-layer address that
uniquely identifies the node on a global scale regardless of global uniquely identifies the node on a global scale, regardless of global
prefix changes. The risk of exposing a G.9959 device from its link- prefix changes. The risk of exposing a G.9959 device from its
layer-derived IID is limited because of the short 8-bit link layer link-layer-derived IID is limited because of the short 8-bit
address. link-layer address.
While intended for central address management, DHCPv6 address While intended for central address management, DHCPv6 address
assignment also decouples the IPv6 address from the link layer assignment also decouples the IPv6 address from the link-layer
address. Addresses may be made dynamic by the use of a short DHCP address. Addresses may be made dynamic by the use of a short DHCP
lease period and an assignment policy which makes the DHCP server lease period and an assignment policy that makes the DHCP server hand
hand out a fresh IP address every time. For enhanced privacy, the out a fresh IP address every time. For enhanced privacy, the
DHCP assigned addresses should be logged only for the duration of the DHCP-assigned addresses should be logged only for the duration of the
lease provided the implementation also allows logging for longer lease, provided the implementation also allows logging for longer
durations as per the operational policies. durations as per the operational policies.
It should be noted that privacy and frequently changing address It should be noted that privacy and frequently changing address
assignment comes at a cost. Non-link-layer-derived IIDs require the assignments come at a cost. Non-link-layer-derived IIDs require the
use of address registration and further, non-link-layer-derived IIDs use of address registration. Further, non-link-layer-derived IIDs
cannot be compressed, which leads to longer datagrams and increased cannot be compressed; this leads to longer datagrams and increased
link layer segmentation. Finally, frequent prefix changes link-layer segmentation. Finally, frequent prefix changes
necessitate more Context Identifier updates, which not only leads to necessitate more Context Identifier updates; this not only leads to
increased traffic but also may affect the battery lifetime of increased traffic but also may affect the battery lifetime of
sleeping nodes. sleeping nodes.
9. Acknowledgements 8. References
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.
10. References
10.1. Normative References 8.1. Normative References
[G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range, [G.9959] International Telecommunication Union, "Short range
narrow-band digital radiocommunication transceivers", narrow-band digital radiocommunication transceivers - PHY
February 2012. and MAC layer specifications", ITU-T Recommendation
G.9959, January 2015,
<http://www.itu.int/rec/T-REC-G.9959>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998,
<http://www.rfc-editor.org/info/rfc2460>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July Unique IDentifier (UUID) URN Namespace", RFC 4122,
2005. July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006,
<http://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011. September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based
DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
2011. August 2011, <http://www.rfc-editor.org/info/rfc6355>.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC_TBD_GHC] [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
"draft-ietf-6lo-ghc: 6LoWPAN Generic Compression of IPv6 over Low-Power Wireless Personal Area Networks
Headers and Header-like Payloads", September 2014. (6LoWPANs)", RFC 7400, November 2014,
<http://www.rfc-editor.org/info/rfc7400>.
10.2. Informative References 8.2. Informative References
[EUI64] IEEE, "GUIIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) [EUI64] IEEE, "Guidelines for 64-bit Global Identifier
REGISTRATION AUTHORITY", IEEE Std http:// (EUI-64TM)", November 2012, <http://standards.ieee.org/
standards.ieee.org/regauth/oui/tutorials/EUI64.html, regauth/oui/tutorials/EUI64.html>.
November 2012.
[KW03] Elsevier's AdHoc Networks Journal, ""Secure Routing in [KW03] Karlof, C. and D. Wagner, "Secure Routing in Sensor
Sensor Networks: Attacks and Countermeasures", Special Networks: Attacks and Countermeasures", Elsevier Ad Hoc
Issue on Sensor Network Applications and Protocols vol 1, Networks Journal, Special Issue on Sensor Network
issues 2-3", , September 2003. Applications and Protocols, vol. 1, issues 2-3,
September 2003.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003,
<http://www.rfc-editor.org/info/rfc3315>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003. Unicast Address Format", RFC 3587, August 2003,
<http://www.rfc-editor.org/info/rfc3587>.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May Discovery (ND) Trust Models and Threats", RFC 3756,
2004. May 2004, <http://www.rfc-editor.org/info/rfc3756>.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, July 2004,
<http://www.rfc-editor.org/info/rfc3819>.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in Martocci, "Reactive Discovery of Point-to-Point Routes in
Low-Power and Lossy Networks", RFC 6997, August 2013. Low-Power and Lossy Networks", RFC 6997, August 2013,
<http://www.rfc-editor.org/info/rfc6997>.
Appendix A. G.9959 6LoWPAN datagram example Appendix A. G.9959 6LoWPAN Datagram Example
This example outlines each individual bit of a sample IPv6 UDP packet 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 arriving to a G.9959 node from a host in the Internet via a PAN
border router. border router.
In the G.9959 PAN, the complete frame has the following fields. In the G.9959 PAN, the complete frame has the following fields.
G.9959: G.9959:
+------+---------+----------+---+-----+----------... +------+---------+----------+---+-----+----------...
|HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID| |HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID|
+------+---------+----------+---+-----+----------+-... +------+---------+----------+---+-----+----------+-...
6LoWPAN: 6LoWPAN:
...+--------------+----------------+-----------------------... ...+--------------+----------------+-----------------------...
|6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers| |6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers|
...-------------+----------------+-----------------------+-... ...-------------+----------------+-----------------------+-...
6LoWPAN, TCP/UDP, App payload: IPv6, TCP/UDP, App payload:
...+-------------------------+------------+-----------+ ...+-------------------------+------------+-----------+
|Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload| |Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload|
...------------------------+------------+-----------+ ...------------------------+------------+-----------+
The frame comes from the source IPv6 address The frame comes from the source IPv6 address
2001:0db8:ac10:ef01::ff:fe00:1206. The source prefix 2001:0db8:ac10:ef01::ff:fe00:1206. The source prefix
2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3. 2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3.
The frame is delivered in direct range from the gateway which has The frame is delivered in direct range from the gateway that has
source NodeID = 1. The Interface Identifier (IID) ff:fe00:1206 is source NodeID = 1. The Interface Identifier (IID) ff:fe00:1206 is
recognised as a link-layer-derived address and is compressed to the recognized as a link-layer-derived address and is compressed to the
16 bit value 0x1206. 16-bit value 0x1206.
The frame is sent to the destination IPv6 address The frame is sent to the destination IPv6 address
2001:0db8:27ef:42ca::ff:fe00:0004. The destination prefix 2001:0db8:27ef:42ca::ff:fe00:0004. The destination prefix
2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2. 2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2.
The Interface Identifier (IID) ff:fe00:0004 is recognised as a link- The IID ff:fe00:0004 is recognized as a link-layer-derived address.
layer-derived address.
Thanks to the link-layer-derived addressing rules, the sender knows 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 that this is to be sent to G.9959 NodeID = 4, targeting the IPv6
interface instance number 0 (the default). interface instance number 0 (the default).
To reach the 6LoWPAN stack of the G.9959 node, (skipping the G.9959 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 header fields), the first octet must be the 6LoWPAN Command Class
(0x4F). (0x4F).
0 0
0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-...
| 0x4F | | 0x4F |
+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-...
The Dispatch header bits '011' advertises a compressed IPv6 header. The Dispatch Header bits '011' advertise a compressed IPv6 header.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 | 0x4F |0 1 1
+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-...
The following bits encode the first IPv6 header fields: The following bits encode the first IPv6 header fields:
TF = '11' : Traffic Class and Flow Label are elided. TF = '11' : Traffic Class and Flow Label are elided
NH = '1' : Next Header is elided NH = '1' : Next Header is elided
HLIM = '10' : Hop limit is 64 HLIM = '10' : Hop limit is 64
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 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| | 0x4F |0 1 1 1 1 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
CID = '1' : CI data follows the DAM field CID = '1' : CI data follows the DAM field
SAC = '1' : Src addr uses stateful, context-based compression SAC = '1' : Src addr uses stateful, context-based compression
SAM = '10' : Use src CID and 16 bits for link-layer-derived addr SAM = '10' : Use src CID and 16 bits for link-layer-derived addr
M = '0' : Dest addr is not a multicast addr M = '0' : Dest addr is not a multicast addr
DAC = '1' : Dest addr uses stateful, context-based compression DAC = '1' : Dest addr uses stateful, context-based compression
skipping to change at page 19, line 16 skipping to change at page 19, line 16
SCI = 0x3 SCI = 0x3
DCI = 0x2 DCI = 0x2
2 3 2 3
4 5 6 7 8 9 0 1 4 5 6 7 8 9 0 1
...+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 | | 0x3 | 0x2 |
...+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-...
IPv6 header fields: IPv6 header fields:
(skipping "version" field) (skipping "version" field)
(skipping "Traffic Class") (skipping "Traffic Class")
(skipping "flow label") (skipping "flow label")
(skipping "payload length") (skipping "payload length")
IPv6 header address fields: IPv6 header address fields:
SrcIP = 0x1206 : Use SCI and 16 LS bits of link-layer-derived address SrcIP = 0x1206 : Use SCI and 16 least significant bits of
link-layer-derived address
(skipping DestIP ) - completely reconstructed from Dest NodeID and DCI (skipping DestIP ) - completely reconstructed from dest NodeID
and DCI
2 3 4 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 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 | | 0x3 | 0x2 | 0x12 | 0x06 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Next header encoding for the UDP header: Next Header encoding for the UDP header:
Dispatch = '11110': Next Header dispatch code for UDP header Dispatch = '11110': Next Header dispatch code for UDP header
C = '0' : 16 bit checksum carried inline C = '0' : 16-bit checksum carried inline
P = '00' : Both src port and dest Port are carried in-line. P = '00' : Both src port and dest port are carried in-line
4 5 4 5
8 9 0 1 2 3 4 5 8 9 0 1 2 3 4 5
...+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-...
|1 1 1 1 0|0|0 0| |1 1 1 1 0|0|0 0|
...+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-...
UDP header fields: UDP header fields:
src Port = 0x1234 src port = 0x1234
dest port = 0x5678 dest port = 0x5678
5 6 7 8 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 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 | | 0x12 | 0x34 | 0x56 | 0x78 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.. ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..
(skipping "length") (skipping "length")
checksum = .... (actual checksum value depends on checksum = .... (actual checksum value depends on
the actual UDP payload) 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...
Appendix B. Change Log
B.1. Changes since -00
o 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.
o Clarified that RFC6282 IPv6 Header Compression MUST be supported.
o Clarified the text of section 5.4 on the use of RFC6775 address
registration in mesh-under networks.
o Split 5.4.2 into multiple paragraphs.
B.2. Changes since -01
o Added this Change Log
o Editorial nits.
o Made IPv6 Header Compression mandatory. Therefore, the Dispatch
value "01 000001 - Uncompressed IPv6 Addresses" was removed from
figure 2.
o 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].
o Changed SHOULD NOT to MUST NOT: Mesh-under networks MUST NOT use
[RFC6775] address registration.
o Changed SHOULD NOT to MUST NOT: [RFC6775] Duplicate Address
Detection (DAD) MUST NOT be used.
o Changed SHOULD NOT to MUST NOT: The CID MUST NOT be reused
immediately;
o Changed SHOULD NOT to MUST NOT: An expired CID and the associated
prefix MUST NOT be reset but rather retained in receive-only mode
o Changed LBR -> ABR
o Changed SHOULD to MUST: , the ABR MUST return an RA with fresh
Context Information to the originator.
o Changed SHOULD NOT to MUST NOT: This value MUST NOT be used by
ABRs. Its use is only intended for a sleeping network controller.
B.3. Changes since -02
o Editorial nits.
o Moved text to the right section so that it does not prohibit DAD
for Route-Over deployments.
o Introduced RA M flag support so that nodes may be instructed to
use DHCPv6 for centralized address assignment.
o Added example appendix: Complete G.9959 6LoWPAN datagram
composition with CID-based header compression.
B.4. Changes since -03
o Corrected error in 6LoWPAN datagram example appendix: 64 hop limit
in comment => also 64 hop limit in actual frame format.
o Added section "Privacy Considerations"
B.5. Changes since -04
o Text on RA M flag support was replaced with a table to improve
clarity.
o Added further details to text on achieving privacy addressing with
DHCP.
B.6. Changes since -05
o Term ABR now points to Authoritative 6LBR as defined by RFC6775.
o 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.
o Clarifying that network controller function redundancy is relevant
for network deployers; not user-level application designers.
o Clarified that RFC2460 specifies that link layer must provide
fragmentation if 1280 octet packets cannot be carried in one piece
by the link layer.
o Clarified that the 6LoWPAN CmdCls identifier value is assigned by
the ITU-T.
o Added reference to Privacy Considerations section from 6LoWPAN
Addressing section.
o Introducing optional GHC header compression.
B.7. Changes since -06
o Added a note to section 5, that the mapping of 802.15.4 terms to 1
similar G.9959 terms applies not only to RFC6282 but also to GHC. 8 9 0
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| (UDP checksum) |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
B.8. Changes since -07 Add your own UDP payload here...
o Added a note to the Privacy considerations section on avoiding Acknowledgements
DHCP logging.
o Added requirements for forming a UUID if DHCPv6 address assignment Thanks to the authors of RFC 4944 and RFC 6282, and members of the
is used. IETF 6LoWPAN working group; this document borrows extensively from
their work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn,
Michael Richardson, and Tommas Jess Christensen for useful comments.
Thanks to Carsten Bormann for extensive feedback that improved this
document significantly. Thanks to Brian Haberman for pointing out
unclear details.
Authors' Addresses Authors' Addresses
Anders Brandt Anders Brandt
Sigma Designs Sigma Designs
Emdrupvej 26A, 1. Emdrupvej 26A, 1.
Copenhagen O 2100 Copenhagen O 2100
Denmark Denmark
Email: anders_brandt@sigmadesigns.com EMail: anders_brandt@sigmadesigns.com
Jakob Buron Jakob Buron
Sigma Designs Sigma Designs
Emdrupvej 26A, 1. Emdrupvej 26A, 1.
Copenhagen O 2100 Copenhagen O 2100
Denmark Denmark
Email: jakob_buron@sigmadesigns.com EMail: jakob_buron@sigmadesigns.com
 End of changes. 168 change blocks. 
477 lines changed or deleted 360 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/