draft-ietf-6lo-lowpanz-05.txt   draft-ietf-6lo-lowpanz-06.txt 
IPv6 over Networks of Resource-constrained Nodes (6lo) WG A. Brandt IPv6 over Networks of Resource-constrained Nodes (6lo) WG A. Brandt
Internet-Draft J. Buron Internet-Draft J. Buron
Intended status: Standards Track Sigma Designs Intended status: Standards Track Sigma Designs
Expires: November 6, 2014 May 5, 2014 Expires: March 22, 2015 September 18, 2014
Transmission of IPv6 packets over ITU-T G.9959 Networks Transmission of IPv6 packets over ITU-T G.9959 Networks
draft-ietf-6lo-lowpanz-05 draft-ietf-6lo-lowpanz-06
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 and 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 Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2014. This Internet-Draft will expire on March 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terms used . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terms used . . . . . . . . . . . . . . . . . . . . . . . 3
2. G.9959 parameters to use for IPv6 transport . . . . . . . . . 4 2. G.9959 parameters to use for IPv6 transport . . . . . . . . . 5
2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 4 2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 5
2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 5 2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 6
2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 6 2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 6
2.4. Transmission status indications . . . . . . . . . . . . . 6 2.4. Transmission status indications . . . . . . . . . . . . . 6
2.5. Transmission security . . . . . . . . . . . . . . . . . . 6 2.5. Transmission security . . . . . . . . . . . . . . . . . . 7
3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 7 3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 7
3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 7 3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 8
4. 6LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . 8 4. 6LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . 9
4.1. Stateless Address Autoconfiguration of routable IPv6 4.1. Stateless Address Autoconfiguration of routable IPv6
addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9
4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 10
4.4. On the use of Neighbor Discovery technologies . . . . . . 10 4.4. On the use of Neighbor Discovery technologies . . . . . . 10
4.4.1. Prefix and CID management (Route-over) . . . . . . . 10 4.4.1. Prefix and CID management (Route-over) . . . . . . . 11
4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 11 4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 11
5. Header Compression . . . . . . . . . . . . . . . . . . . . . 12 5. Header Compression . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 15 Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 16
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 19 B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 19
B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 19 B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 20
B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 20 B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 20
B.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 20 B.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 B.5. Changes since -04 . . . . . . . . . . . . . . . . . . . . 21
B.6. Changes since -05 . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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
skipping to change at page 3, line 33 skipping to change at page 3, line 35
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 of
this document. this document.
1.1. Terms used 1.1. Terms used
6LoWPAN: IPv6-based Low-power Personal Area Network 6LoWPAN: IPv6-based Low-power Personal Area Network
ABR: Authoritative Border Router ([RFC6775]) ABR: Authoritative 6LBR ([RFC6775])
Ack: Acknowedgement Ack: Acknowedgement
AES: Advanced Encryption Scheme AES: Advanced Encryption Scheme
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]) EUI-64: Extended Unique Identifier ([EUI64])
G.9959: Short range, narrow-band digital radiocommunication
transceiver ([G.9959])
GHC: Generic Header Compression ([RFC_TBD_GHC])
HomeID: G.9959 Link-Layer Network Identifier HomeID: G.9959 Link-Layer Network Identifier
IID: Interface IDentifier IID: Interface IDentifier
ITU G.9959: Short range, narrow-band digital radiocommunication
transceiver ([G.9959])
Link-layer-derived address: IPv6 Address constructed on basis of link Link-layer-derived address: IPv6 Address constructed on basis of link
layer address information 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
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 2. G.9959 parameters to use for IPv6 transport
This chapter outlines properties applying to the PHY and MAC of This chapter outlines properties applying to the PHY and MAC of
G.9959 and how to use these for IPv6 transport. G.9959 and how to use these for IPv6 transport.
2.1. Addressing mode 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. NodeIDs are unique within the network identifier is allocated to each node. NodeIDs are unique within the
identified by the HomeID. The G.9959 network controller function network identified by the HomeID. The G.9959 HomeID represents an
SHOULD be integrated in the ABR. The G.9959 HomeID represents an
IPv6 subnet which is identified by one or more IPv6 prefixes. IPv6 subnet which 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. The M flag MUST be construction of routable IPv6 addresses. A cost optimized node
interpreted as defined in Figure 1. implementation may save memory by skipping support for the M flag.
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 |
skipping to change at page 5, line 35 skipping to change at page 5, line 49
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].
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 is 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 to 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 deployers of high-reliability applications controller suggests that high-reliability network deployments may
should carefully consider adding redundancy to the network controller benefit from a redundant network controller function.
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 subnet-
wide multicast is not supported natively by G.9959. Subnet-wide wide multicast is not supported natively by G.9959. Subnet-wide
multicast may be provided by an IP routing protocol or a mesh routing multicast may be provided by an IP routing protocol or a mesh routing
skipping to change at page 6, line 21 skipping to change at page 6, line 35
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 IPv6 packets may be up to 1280 octets. [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.
G.9959 provides Segmentation And Reassembly for payloads up to 1350 G.9959 provides Segmentation And Reassembly for payloads up to 1350
octets. IPv6 Header Compression [RFC6282] improves the chances that octets. IPv6 Header Compression [RFC6282] improves the chances that
a short IPv6 packet can fit into a single G.9959 frame. Therefore, a short IPv6 packet can fit into a single G.9959 frame. Therefore,
section Section 3 specifies that [RFC6282] MUST be supported. With section Section 3 specifies that [RFC6282] MUST be supported. With
the mandatory link-layer security enabled, a G.9959 R3 MAC PDU may the mandatory link-layer security enabled, a G.9959 R3 MAC PDU may
accommodate 6LoWPAN datagrams of up to 130 octets without triggering accommodate 6LoWPAN datagrams of up to 130 octets without triggering
G.9959 Segmentation and Reassembly (SAR). Longer 6LoWPAN datagrams G.9959 Segmentation and Reassembly (SAR). Longer 6LoWPAN datagrams
will lead to the transmission of multiple G.9959 PDUs. will lead to the transmission of multiple G.9959 PDUs.
skipping to change at page 7, line 9 skipping to change at page 7, line 25
applications with high or very high requirements on confidentiality applications with high or very high requirements on 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 chapter 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. MUST be supported by implementations of this specification. Further,
implementations MAY support Generic Header Compression (GHC)
[RFC_TBD_GHC]. A node implementing [RFC_TBD_GHC] MUST probe its
peers for GHC support before applying GHC compression.
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.
skipping to change at page 7, line 44 skipping to change at page 8, line 18
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 specifies that the carry the value 0x4F [G.9959]. The value is assigned by the ITU-T
following bits are a 6LoWPAN encapsulated datagram. 6LoWPAN protocols and specifies that the following bits are a 6LoWPAN encapsulated
MUST ignore the G.9959 frame if the 6LoWPAN Command Class identifier datagram. 6LoWPAN protocols MUST ignore the G.9959 frame if the
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
skipping to change at page 8, line 30 skipping to change at page 9, line 7
| 01 1xxxxx | 6LoWPAN_IPHC - Compressed IPv6 Addresses | [RFC6282] | | 01 1xxxxx | 6LoWPAN_IPHC - Compressed IPv6 Addresses | [RFC6282] |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
All other Dispatch values are unassigned in this document. 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 are autoconfigured from IIDs which are again IPv6 addresses may be autoconfigured from IIDs which 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]. [RFC6282]. Link-layer-derived addresses have a static nature and may
involuntarily expose private usage data on public networks. Refer to
Section 8.
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 one byte value chosen
by the individual node. The default YY value MUST be zero. A node 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 MAY use other values of YY than zero to form additional IIDs in order
skipping to change at page 12, line 9 skipping to change at page 12, line 24
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 according to IPv6 header compression MUST be implemented according to [RFC6282].
[RFC6282]. This section will simply identify substitutions that This section will simply identify substitutions that should be made
should be made when interpreting the text of [RFC6282]. when interpreting the text of [RFC6282].
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
skipping to change at page 12, line 35 skipping to change at page 12, line 50
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. which 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 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
skipping to change at page 14, line 16 skipping to change at page 14, line 30
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 9. Acknowledgements
Thanks to the authors of RFC 4944 and RFC 6282 and members of the Thanks to the authors of RFC 4944 and RFC 6282 and members of the
IETF 6LoWPAN working group; this document borrows extensively from IETF 6LoWPAN working group; this document borrows extensively from
their work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn, their work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn,
Michael Richardson, Tommas Jess Christensen for useful comments. Michael Richardson, Tommas Jess Christensen for useful comments.
Thanks to Carsten Bormann for extensive feedback which improved this Thanks to Carsten Bormann for extensive feedback which improved this
document significantly. document significantly. Thanks to Brian Haberman for pointing out
unclear details.
10. References 10. References
10.1. Normative References 10.1. Normative References
[G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range, [G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range,
narrow-band digital radiocommunication transceivers", narrow-band digital radiocommunication transceivers",
February 2012. February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 15, line 10 skipping to change at page 15, line 22
[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.
[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.
[RFC_TBD_GHC]
"draft-ietf-6lo-ghc: 6LoWPAN Generic Compression of
Headers and Header-like Payloads", September 2014.
10.2. Informative References 10.2. Informative References
[EUI64] IEEE, "GUIIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) [EUI64] IEEE, "GUIIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
REGISTRATION AUTHORITY", IEEE Std http:// REGISTRATION AUTHORITY", IEEE Std http://
standards.ieee.org/regauth/oui/tutorials/EUI64.html, standards.ieee.org/regauth/oui/tutorials/EUI64.html,
November 2012. November 2012.
[KW03] Elsevier's AdHoc Networks Journal, ""Secure Routing in [KW03] Elsevier's AdHoc Networks Journal, ""Secure Routing in
Sensor Networks: Attacks and Countermeasures", Special Sensor Networks: Attacks and Countermeasures", Special
Issue on Sensor Network Applications and Protocols vol 1, Issue on Sensor Network Applications and Protocols vol 1,
skipping to change at page 20, line 32 skipping to change at page 20, line 45
o Changed SHOULD NOT to MUST NOT: An expired CID and the associated 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 prefix MUST NOT be reset but rather retained in receive-only mode
o Changed LBR -> ABR o Changed LBR -> ABR
o Changed SHOULD to MUST: , the ABR MUST return an RA with fresh o Changed SHOULD to MUST: , the ABR MUST return an RA with fresh
Context Information to the originator. Context Information to the originator.
o Changed SHOULD NOT to MUST NOT: This value MUST NOT be used by 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; ABRs. Its use is only intended for a sleeping network controller.
B.3. Changes since -02 B.3. Changes since -02
o Editorial nits. o Editorial nits.
o Moved text to the right section so that it does not prohibit DAD o Moved text to the right section so that it does not prohibit DAD
for Route-Over deployments. for Route-Over deployments.
o Introduced RA m flag support so that nodes may be instructed to o Introduced RA M flag support so that nodes may be instructed to
use DHCPv6 for centralized address assignment. use DHCPv6 for centralized address assignment.
o Added example appendix: Complete G.9959 6LoWPAN datagram o Added example appendix: Complete G.9959 6LoWPAN datagram
composition with CID-based header compression composition with CID-based header compression.
B.4. Changes since -03 B.4. Changes since -03
o Corrected error in 6LoWPAN datagram example appendix: 64 hop limit o Corrected error in 6LoWPAN datagram example appendix: 64 hop limit
in comment => also 64 hop limit in actual frame format. in comment => also 64 hop limit in actual frame format.
o Added section "Privacy Considerations" 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.
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
 End of changes. 33 change blocks. 
45 lines changed or deleted 95 lines changed or added

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