Transmission of IPv6 packets over ITU-T
G.9959 NetworksSigma DesignsEmdrupvej 26A, 1.Copenhagen O2100Denmarkanders_brandt@sigmadesigns.comSigma DesignsEmdrupvej 26A, 1.Copenhagen O2100Denmarkjakob_buron@sigmadesigns.com
Internet Area
IPv6 Maintenance WGZ-WaveIP over fooThis document describes the frame format for transmission of IPv6
packets and a method of forming IPv6 link-local addresses and
statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.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 .This chapter MUST be deleted before going for document last call.This document borrows heavily from RFC4944, "Transmission of IPv6
Packets over IEEE 802.15.4 Networks". The process of creating this
document was mainly a simplification; removing the following
topics:EUI-64 link-layer addressesFragmentation layerMesh routingThe 16-bit short addresses of 802.15.4 have been changed to 8-bit
G.9959 NodeIDs.The ITU-T G.9959 recommendation targets
low-power Personal Area Networks (PANs). This document defines the frame
format for transmission of IPv6 packets as well
as the formation of IPv6 link-local addresses and statelessly
autoconfigured IPv6 addresses on G.9959 networks.The general approach is to adapt elements of
to G.9959 networks. G.9959 provides a Segmentation and Reassembly (SAR)
layer for transmission of datagrams larger than the G.9959 MAC PDU. updates by
specifying LoWPAN optimizations for IPv6 Neighbor Discovery (ND)
(originally defined by ). This document limits
the use of to prefix and Context ID assignment.
It is described how to construct an IID from a G.9959 link-layer
address. Refer to . If using that
method, Duplicate Address Detection (DAD) is not needed. Address
registration is only needed in certain cases.In addition to IPv6 application communication, the frame format
defined in this document may be used by IPv6 routing protocols such as
RPL or P2P-RPL to implement IPv6 routing over G.9959
networks.G.9959 networks may implement mesh routing between nodes below the IP
layer. Mesh routing is out of scope of this document.ABR: Authoritative Border Router ()AES: Advanced Encryption SchemeEUI-64: Extended Unique IdentifierHomeID: G.9959 Link-Layer Network IdentifierIID: Interface IDentifierMAC: Media Access ControlMTU: Maximum Transmission UnitNodeID: G.9959 Link-Layer Node Identifier (Short Address)PAN: Personal Area NetworkPDU: Protocol Data UnitSAR: Segmentation And ReassemblyULA: Unique Local AddressThis chapter outlines properties applying to the PHY and MAC of
G.9959 and how to use these for IPv6 transport.G.9959 defines how a unique 32-bit HomeID network identifier is
assigned by a network controller and how an 8-bit NodeID host
identifier is allocated. NodeIDs are unique within the logical network
identified by the HomeID. The logical network identified by the HomeID
maps directly to an IPv6 subnet identified by one or more IPv6
prefixes.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 .A word of caution: since HomeIDs and NodeIDs are handed out by a
network controller function during inclusion, identifier validity and
uniqueness is limited by the lifetime of the logical network
membership. This can be cut short by a mishap occurring to the network
controller. Having a single point of failure at the network controller
suggests that deployers of high-reliability applications should
carefully consider adding redundancy to the network controller
function. recommends that IP subnetworks support
(subnet-wide) multicast. G.9959 supports direct-range IPv6 multicast
while subnet-wide multicast is not supported natively by G.9959.
Subnet-wide multicast may be provided by an IP routing protocol or a
mesh routing protocol operating below the LoWPAN layer. Routing
protocols are out of scope of this document.IPv6 multicast packets MUST be carried via G.9959 broadcast.As per , this is accomplished as
follows:The destination HomeID of the G.9959 MAC PDU MUST be the HomeID
of the logical networkThe destination NodeID of the G.9959 MAC PDU MUST be the
broadcast NodeID (0xff)G.9959 broadcast MAC PDUs are only intercepted by nodes
within the logical network identified by the HomeID.IPv6 packets MUST use G.9959 transmission profiles which support
MAC PDU payload sizes of 150 bytes or higher, e.g. the R3 profile.
G.9959 profiles R1 and R2 only supports MPDU payloads around 40 bytes
and the transmission speed is down to 9.6kbit/s. specifies that IPv6 packets may be up to
1280 octets. However, a full IPv6 packet does not fit in an G.9959 MAC
PDU. The maximum G.9959 R3 MAC PDU payload size is 158 octets.
Link-layer security imposes an overhead, which in the extreme case
leaves 130 octets available.G.9959 provides Segmentation And Reassembly for payloads up to 1350
octets. Segmentation however adds further overhead. It is therefore
desirable that datagrams can fit into a single G.9959 MAC PDU. IPv6
Header Compression improves the chances that
a short IPv6 packet can fit into a single G.9959 frame.The G.9959 MAC layer provides native acknowledgement and
retransmission of MAC PDUs. The G.9959 SAR layer does the same for
larger datagrams. A mesh routing layer may provide a similar feature
for routed communication. Acknowledgment and retransmission improves
the transmission success rate and frees higher layers from the burden
of implementing individual retransmission schemes. An IPv6 routing
stack communicating over G.9959 may utilize link-layer status
indications such as delivery confirmation and Ack timeout from the MAC
layer.Implementations claiming conformance with this document MUST enable
G.9959 common network key security.The network key is intended to address security requirements in the
home at the normal security requirements level. For applications with
high or very high requirements on confidentiality and/or integrity,
such as door locks and meters, additional application layer security
measures for end-to-end authentication and encryption will need to be
applied. The availability of the network relies on the security
properties of the network key in any case.The LoWPAN encapsulation formats defined in this chapter are the
payload in the G.9959 MAC PDU. IPv6 header compression MUST be supported by implementations of this
specification.All LoWPAN datagrams transported over G.9959 are prefixed by a LoWPAN
encapsulation header stack. The LoWPAN payload (e.g. an IPv6 packet)
follows this encapsulation header. Each header in the header stack
contains a header type followed by zero or more header fields. An IPv6
header stack may contain, in the following order, addressing, hop-by-hop
options, routing, fragmentation, destination options, and finally
payload . The LoWPAN header format is structured
the same way. Currently only payload options are defined for the LoWPAN
header format.The definition of LoWPAN headers consists of the dispatch value, the
definition of the header fields that follow, and their ordering
constraints relative to all other headers. Although the header stack
structure provides a mechanism to address future demands on the LoWPAN
adaptation layer, it is not intended to provide general purpose
extensibility. This document specifies a small set of 6LoWPAN header
types using the 6LoWPAN header stack for clarity, compactness, and
orthogonality.The dispatch header is shown below:LoWPAN CmdCls: LoWPAN Command Class identifier, . Specifies that the following bits are a LoWPAN
encapsulated datagram. Non-LoWPAN protocols MUST ignore the contents
following the LoWPAN Command Class identifier. TBD: Specific value to
be assigned by Z-Wave Alliance before last call of this Internet
Draft. Refer to .Dispatch: Identifies the header type immediately following the
Dispatch Header.Type-specific header: A header determined by the Dispatch
Header.The dispatch value may be treated as an unstructured namespace.
Only a few symbols are required to represent current LoWPAN
functionality. Although some additional savings could be achieved by
encoding additional functionality into the dispatch byte, these
measures would tend to constrain the ability to address future
alternatives.Dispatch values used in this specification are compatible with the
dispatch values defined by and .IPv6: Specifies that the following header is an uncompressed IPv6
header.LoWPAN_IPHC: IPv6 Header Compression. Refer to .IPv6 addresses are autoconfigured from IIDs which are again
constructed from link-layer address information to save memory in
devices and to facilitate efficient IP header compression as per .A G.9959 NodeID is 8 bits in length. A NodeID is mapped into an IEEE
EUI-64 identifier as follows:where XX carries the G.9959 NodeID and YY is a one byte value chosen
by the individual node. The default YY value MUST be zero. A node MAY
use other values of YY than zero to form additional IIDs in order to
instantiate multiple IPv6 interfaces. The YY value MUST be ignored when
computing the corresponding NodeID (the XX value) from an IID.A LoWPAN network typically is used for M2M-style communication. The
method of constructing IIDs from the link-layer address obviously does
not support addresses assigned or constructed by other means. A node
MUST NOT compute the NodeID from the IID if the first 6 bytes of the IID
do not comply with the format defined in . In that case, the address resolution
mechanisms of RFC 6775 apply.The IID defined above MUST be used whether autoconfiguring a ULA
IPv6 address or a globally routable IPv6
address in G.9959 subnets.The IPv6 link-local address for a G.9959
interface is formed by appending the IID defined above to the IPv6
link local prefix FE80::/64.The "Universal/Local" (U/L) bit MUST be set to zero in keeping with
the fact that this is not a globally unique value .The resulting link local address is formed as follows:The address resolution procedure for mapping IPv6 unicast addresses
into G.9959 link-layer addresses follows the general description in
Section 7.2 of . The Source/Target Link-layer
Address option MUST have the following form when the link layer is
G.9959.Option fields:Type: The value 1 signifies the Source Link-layer address. The
value 2 signifies the Destination Link-layer address.Length: This is the length of this option (including the type and
length fields) in units of 8 octets. The value of this field is always
1 for G.9959 NodeIDs.NodeID: This is the G.9959 NodeID the actual interface currently
responds to. The link-layer address may change if the interface joins
another network at a later time. specifies how IPv6 nodes may resolve link
layer addresses from IPv6 addresses via the use of link-local IPv6
multicast. is an optimization of , specifically targeting LoWPAN networks. defines how a LoWPAN node may register IPv6
addresses with an authoritative border router (ABR). Generally, nodes
SHOULD NOT use address registration. However,
address registration MUST be used if the first 6 bytes of the IID do
not comply with the format defined in Figure 3.In route-over environments, IPv6 hosts MUST use address registration.
Duplicate Address Detection (DAD) SHOULD NOT be used, since the
link-layer inclusion process of G.9959 ensures that a NodeID is unique
for a given HomeID.A node implementation for route-over operation MAY use RFC6775
mechanisms for obtaining IPv6 prefixes and corresponding header
compression context information . RFC6775
Route-over requirements apply with no modifications.An implementation for mesh-under operation MUST use mechanisms for managing IPv6 prefixes and
corresponding header compression context information . When using mechanisms
for sending RAs, the M flag MUST NOT be set. As stated by , an ABR is responsible for managing prefix(es).
Global prefixes may change over time. It is RECOMMENDED that a ULA
prefix is always assigned to the LoWPAN subnet to facilitate stable
site-local application associations based on IPv6 addresses.
Prefixes used in the LoWPAN subnet are distributed by normal RA
mechanisms. The 6LoWPAN Context Option (6CO) is used according to
in an RA to disseminate Context IDs (CID)
to use for compressing prefixes. Prefixes and corresponding Context
IDs MUST be assigned during initial node inclusion. Nodes MUST renew
the prefix and CID according to the lifetime signaled by the ABR.
specifies that the maximum value of the RA
Router Lifetime field MAY be up to 0xFFFF. This document further
specifies that the value 0xFFFF MUST be interpreted as infinite
lifetime. This value SHOULD NOT be used by ABRs. Its use is only
intended for a sleeping network controller; for instance a battery
powered remote control being master for a small island-mode network
of light modules. CIDs SHOULD be used in a cyclic fashion to assist
battery powered nodes with no real-time clock. When updating context
information, a CID may have its lifetime set to zero to obsolete it.
The CID SHOULD NOT be reused immediately; rather the next vacant CID
should be assigned. An ABR detecting the use of an obsoleted CID
SHOULD immediately send an RA with updated Context Information.
Header compression based on CIDs MUST NOT be used for RA messages
carrying Context Information. An expired CID and the associated
prefix SHOULD NOT be reset but rather retained in receive-only mode
if there is no other current need for the CID value. This will allow
an ABR to detect if a sleeping node without clock uses an expired
CID and in response, the LBR SHOULD immediately return an RA with
fresh Context Information to the originator. Except for the specific
redefinition of the RA Router Lifetime value 0xFFFF, the above text
is in compliance with .IPv6 header fields SHOULD be compressed. If IPv6 header compression
is used, it MUST be according to . This section
will simply identify substitutions that should be made when interpreting
the text of [RFC6282].In general the following substitutions should be made:Replace "802.15.4" with "G.9959"Replace "802.15.4 short address" with
"<Interface><G.9959 NodeID>"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 address") it MUST be formed by prepending an Interface label byte
to the G.9959 NodeID:A transmitting node may be sending to an IPv6
destination address which can be reconstructed from the link-layer
destination address. If the Interface number is zero (the default
value), all IPv6 address bytes may be elided. Likewise, the Interface
number of a fully elided IPv6 address (i.e. SAM/DAM=11) may be
reconstructed to the value zero by a receiving node.64 bit 802.15.4 address details MUST be ignored. This document only
specifies the use of short addresses.This document makes no request of IANA.Note to RFC Editor: this section may be removed on publication as an
RFC.This document requests that the Z-Wave Alliance assigns a Command
Class identifier for the LoWPAN Command Class; refer to .Note to RFC Editor: this section may be removed on publication as an
RFC.The method of derivation of Interface Identifiers from 8-bit NodeIDs
preserves uniqueness within the logical network. However, there is no
protection from duplication through forgery. Neighbor Discovery in
G.9959 links may be susceptible to threats as detailed in . G.9959 networks may feature mesh routing. This
implies additional threats due to ad hoc routing as per [KW03]. G.9959
provides capability for link-layer security. G.9959 nodes MUST use
link-layer security with a common key. Doing so will alleviate the
majority of threats stated above. A sizeable portion of G.9959 devices
is expected to always communicate within their PAN (i.e., within their
subnet, in IPv6 terms). In response to cost and power consumption
considerations, these devices will typically implement the minimum set
of features necessary. Accordingly, security for such devices may rely
on the mechanisms defined at the link layer by G.9959. G.9959 relies on
the Advanced Encryption Standard (AES) for authentication and encryption
of G.9959 frames and further employs challenge-response handshaking to
prevent replay attacks.It is also expected that some G.9959 devices (e.g. billing and/or
safety critical products) will implement coordination or integration
functions. These may communicate regularly with IPv6 peers outside the
subnet. Such IPv6 devices are expected to secure their end-to-end
communications with standard security mechanisms (e.g., IPsec, TLS,
etc).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 Kerry Lynn, Tommas Jess Christensen and Erez Ben-Tovim
for useful discussions which helped shape this document.G.9959: Low-Power, narrowband radio for control
applicationsITU-TG.9959 Contribution: Logical Link Control (LLC) layerITU-TG.9959 Contribution: Segmentation And Reassembly (SAR)
adaptation layerITU-TGUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION
AUTHORITYIEEEIETF, I-D.ietf-roll-p2p-rpl-15, Reactive Discovery of
Point-to-Point Routes in Low Power and Lossy NetworksUniversity of WisconsinINRIAINRIASigma DesignsJohnson Controls