< draft-ietf-6lo-lowpanz-02.txt   draft-ietf-6lo-lowpanz-03.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: August 7, 2014 February 3, 2014 Expires: September 5, 2014 March 4, 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-02 draft-ietf-6lo-lowpanz-03
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 August 7, 2014. This Internet-Draft will expire on September 5, 2014.
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 . . . . . . . . . 3 2. G.9959 parameters to use for IPv6 transport . . . . . . . . . 4
2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 4 2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 4
2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 4 2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 4
2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 5 2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 5
2.4. Transmission status indications . . . . . . . . . . . . . 5 2.4. Transmission status indications . . . . . . . . . . . . . 5
2.5. Transmission security . . . . . . . . . . . . . . . . . . 5 2.5. Transmission security . . . . . . . . . . . . . . . . . . 5
3. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 6 3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 6
3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 6 3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 6
4. LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . . 7 4. 6LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . 7
4.1. Stateless Address Autoconfiguration of routable IPv6 4.1. Stateless Address Autoconfiguration of routable IPv6
addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8
4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 8 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 8
4.4. On the use of Neighbor Discovery technologies . . . . . . 9 4.4. On the use of Neighbor Discovery technologies . . . . . . 9
4.4.1. Prefix and CID management (Route-over) . . . . . . . 9 4.4.1. Prefix and CID management (Route-over) . . . . . . . 9
4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 10 4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 10
5. Header Compression . . . . . . . . . . . . . . . . . . . . . 11 5. Header Compression . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 14
A.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17
A.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 14 B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 18
B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 MAC PDU.
[RFC6775] updates [RFC4944] by specifying 6LoWPAN optimizations for [RFC6775] updates [RFC4944] by specifying 6LoWPAN optimizations for
IPv6 Neighbor Discovery (ND) (originally defined by [RFC4861]). This 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. It is described how to construct an IID from a G.9959 assignment. An IID may be constructed from a G.9959 link-layer
link-layer address. If using that method, Duplicate Address address, leading to a "link-layer-derived IPv6 address". If using
Detection (DAD) is not needed. Address registration is only needed that method, Duplicate Address Detection (DAD) is not needed.
in certain cases. Alternatively, IPv6 addresses may be assigned centrally via DHCP,
leading to a "non-link-layer-derived IPv6 address". Address
registration is only needed in certain cases.
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 RPL [RFC6550] or 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. Routing be transported via mesh routing below the 6LoWPAN layer. Routing
protocol specifications are out of scope of this document. protocol specifications are out of scope of this document.
1.1. Terms used 1.1. Terms used
6LoWPAN: IPv6-based Low-power Personal Area Network
ABR: Authoritative Border Router ([RFC6775]) ABR: Authoritative Border Router ([RFC6775])
AES: Advanced Encryption Scheme AES: Advanced Encryption Scheme
EUI-64: Extended Unique Identifier EUI-64: Extended Unique Identifier
HomeID: G.9959 Link-Layer Network Identifier HomeID: G.9959 Link-Layer Network Identifier
IID: Interface IDentifier IID: Interface IDentifier
skipping to change at page 3, line 45 skipping to change at page 4, line 4
MTU: Maximum Transmission Unit MTU: Maximum Transmission Unit
NodeID: G.9959 Link-Layer Node Identifier (Short Address) NodeID: G.9959 Link-Layer Node Identifier (Short Address)
PAN: Personal Area Network PAN: Personal Area Network
PDU: Protocol Data Unit PDU: Protocol Data Unit
SAR: Segmentation And Reassembly SAR: Segmentation And Reassembly
ULA: Unique Local Address ULA: Unique Local Address
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 logical identifier is allocated. NodeIDs are unique within the logical
network identified by the HomeID. The logical network identified by network identified by the HomeID. The logical network identified by
the HomeID maps directly to an IPv6 subnet identified by one or more the HomeID maps directly to an IPv6 subnet identified by one or more
IPv6 prefixes. IPv6 prefixes.
An IPv6 host MUST construct its link-local IPv6 address and routable An IPv6 host MUST construct its link-local IPv6 address from the
IPv6 addresses from the NodeID in order to facilitate IP header link-layer-derived IID in order to facilitate IP header compression
compression as described in [RFC6282]. as described in [RFC6282].
A node interface MAY support the M flag of the RA message for the
construction of routable IPv6 addresses. If the M flag is not
supported, link-layer-derived addressing MUST be used. If the M flag
is supported, link-layer-derived addressing MUST be used if the M
flag is 0, while DHCPv6 address assignment MUST be used if the M flag
is 1. Nodes using DHCPv6 assigned IPv6 addresses MUST comply with
[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 logical network uniqueness is limited by the lifetime of the logical network
membership. This can be cut short by a mishap occurring to the membership. This can be cut short by a mishap occurring to the
network controller. Having a single point of failure at the network network controller. Having a single point of failure at the network
controller suggests that deployers of high-reliability applications controller suggests that deployers of high-reliability applications
should carefully consider adding redundancy to the network controller should carefully consider adding redundancy to the network controller
function. function.
This warning applies to link-layer-derived addressing as well as to
non-link-layer 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
protocol operating below the 6LoWPAN layer. Routing protocol protocol operating below the 6LoWPAN layer. Routing protocol
specifications are out of scope of this document. specifications are out of scope of this document.
IPv6 multicast packets MUST be carried via G.9959 broadcast. IPv6 multicast packets MUST be carried via G.9959 broadcast.
skipping to change at page 5, line 8 skipping to change at page 5, line 21
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
logical network identified by the HomeID. logical 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 use G.9959 transmission profiles which support MAC IPv6 packets MUST use G.9959 transmission profiles which support MAC
PDU payload sizes of 150 bytes or higher, e.g. the R3 profile. PDU payload sizes of 150 bytes or higher, i.e. profile R3 or higher.
G.9959 profiles R1 and R2 only supports MPDU payloads around 40 bytes (G.9959 profiles R1 and R2 only support MPDU payloads around 40 bytes
and the transmission speed is down to 9.6kbit/s. and the transmission speed is down to 9.6kbit/s)
[RFC2460] specifies that IPv6 packets may be up to 1280 octets. [RFC2460] 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 G.9959 provides Segmentation And Reassembly for payloads up to 1350
octets. Segmentation however adds further overhead. It is desirable octets. IPv6 Header Compression [RFC6282] improves the chances that
that datagrams can fit into a single G.9959 MAC PDU. IPv6 Header a short IPv6 packet can fit into a single G.9959 frame. Therefore,
Compression [RFC6282] improves the chances that a short IPv6 packet section Section 3 specifies that [RFC6282] MUST be supported. With
can fit into a single G.9959 frame. Therefore, section Section 3 the mandatory link-layer security enabled, a G.9959 R3 MAC PDU may
specifies that [RFC6282] MUST be supported. accommodate 6LoWPAN datagrams of up to 130 octets without triggering
G.9959 Segmentation and Reassembly. 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. Acknowledgment and retransmission improves for routed communication. An IPv6 routing stack communicating over
the transmission success rate and frees higher layers from the burden G.9959 may utilize link-layer status indications such as delivery
of implementing individual retransmission schemes. An IPv6 routing confirmation and Ack timeout from the MAC layer.
stack communicating over G.9959 may utilize link-layer status
indications such as delivery 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 security requirements level. For
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. The end-to-end authentication and encryption may need to be applied.
availability of the network relies on the security properties of the (The availability of the network relies on the security properties of
network key in any case. the network key in any case)
3. LoWPAN 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.
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 (e.g. an 6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this
IPv6 packet) follows this encapsulation header. Each header in the encapsulation header stack. Each header in the header stack contains
header stack contains a header type followed by zero or more header a header type followed by zero or more header fields. An IPv6 header
fields. An IPv6 header stack may contain, in the following order, stack may contain, in the following order, addressing, hop-by-hop
addressing, hop-by-hop options, routing, fragmentation, destination options, routing, fragmentation, destination options, and finally
options, and finally payload [RFC2460]. The 6LoWPAN header format is payload [RFC2460]. The 6LoWPAN header format is structured the same
structured the same way. Currently only payload options are defined way. Currently only one payload option is defined for the G.9959
for the 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. This document specifies a small set of purpose extensibility.
6LoWPAN header types using the 6LoWPAN header stack for clarity,
compactness, and orthogonality. An example of a complete G.9959 6LoWPAN datagram can be found in
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 26 skipping to change at page 7, line 33
| Pattern | Header Type | Reference | | Pattern | Header Type | Reference |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| 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 2: Dispatch values Figure 2: Dispatch values
6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282]. 6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282].
4. LoWPAN addressing 4. 6LoWPAN addressing
IPv6 addresses are autoconfigured from IIDs which are again IPv6 addresses are autoconfigured from IIDs which are again
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].
A G.9959 NodeID is 8 bits in length. A NodeID is mapped into an IEEE A NodeID is mapped into an IEEE EUI-64 identifier as follows:
EUI-64 identifier as follows:
IID = 0000:00ff:fe00:YYXX IID = 0000:00ff:fe00:YYXX
Figure 3: Constructing a compressible IID Figure 3: 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
to instantiate multiple IPv6 interfaces. The YY value MUST be to instantiate multiple IPv6 interfaces. The YY value MUST be
ignored when computing the corresponding NodeID (the XX value) from ignored when computing the corresponding NodeID (the XX value) from
an IID. an IID.
A 6LoWPAN network typically is used for M2M-style communication. The The method of constructing IIDs from the link-layer address obviously
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 3. In that the IID do not comply with the format defined in Figure 3. In that
case, the address resolution mechanisms of RFC 6775 apply. case, the address resolution mechanisms of RFC 6775 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.
skipping to change at page 9, line 43 skipping to change at page 9, line 43
[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 3.
In route-over environments, IPv6 hosts MUST use [RFC6775] address
registration. [RFC6775] Duplicate Address Detection (DAD) MUST NOT
be used, since the link-layer inclusion process of G.9959 ensures
that a NodeID is unique for a given HomeID.
4.4.1. Prefix and CID management (Route-over) 4.4.1. Prefix and CID management (Route-over)
A node implementation for route-over operation MAY use RFC6775 In route-over environments, IPv6 hosts MUST use [RFC6775] address
mechanisms for obtaining IPv6 prefixes and corresponding header registration. A node implementation for route-over operation MAY use
compression context information [RFC6282]. RFC6775 Route-over RFC6775 mechanisms for obtaining IPv6 prefixes and corresponding
header compression context information [RFC6282]. RFC6775 Route-over
requirements apply with no modifications. 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]. Except for the specific compression context information [RFC6282]. [RFC6775] Duplicate
redefinition of the RA Router Lifetime value 0xFFFF (refer to Address Detection (DAD) MUST NOT be used, since the link-layer
Section 4.4.2.3), the text of the following subsections is in inclusion process of G.9959 ensures that a NodeID is unique for a
compliance with [RFC6775]. given HomeID.
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
following subsections is in compliance with [RFC6775].
4.4.2.1. Prefix assignment considerations 4.4.2.1. Prefix assignment considerations
When using [RFC6775] mechanisms for sending RAs, the M flag MUST NOT As stated by [RFC6775], an ABR is responsible for managing
be set. As stated by [RFC6775], an ABR is responsible for managing prefix(es). Global routable prefixes may change over time. It is
prefix(es). Global prefixes may change over time. It is RECOMMENDED RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to
that a ULA prefix is always 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. Prefixes used in the 6LoWPAN subnet are distributed by addresses. A node MAY support the M flag of the RA message. If the
normal RA mechanisms. M flag is not supported, link-layer-derived addressing MUST be used.
If the M flag is supported, link-layer-derived addressing MUST be
used if the M flag is 0, while DHCPv6 address assignment MUST be used
if the M flag is 1.
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 (CID) to use for compressing prefixes.
Prefixes and corresponding Context IDs MUST be assigned during One or more prefixes and corresponding Context IDs MUST be assigned
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 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 the CID value. This will allow an ABR to detect if a sleeping node
without clock uses an expired CID and in response, the ABR MUST without clock uses an expired CID and in response, the ABR MUST
return an RA with fresh Context Information to the originator. return an RA with fresh Context Information to the originator.
skipping to change at page 11, line 38 skipping to change at page 11, line 40
| 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 MUST be ignored. This document only 64 bit 802.15.4 address details do not apply.
specifies the use of short addresses.
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.
7. Security Considerations 7. Security Considerations
skipping to change at page 14, line 19 skipping to change at page 14, line 19
[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.
[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.
Appendix A. Change Log Appendix A. G.9959 6LoWPAN datagram example
A.1. Changes since -00 This example outlines each individual bit of a sample IPv6 UDP packet
arriving to a G.9959 node from a host in the Internet
via a PAN border router.
o Clarified that mesh-under routing may take place below the 6lowpan In the G.9959 PAN, the complete frame has the following fields.
G.9959:
+------+---------+----------+---+-----+----------...
|HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID|
+------+---------+----------+---+-----+----------+-...
6LoWPAN:
...+--------------+----------------+-----------------------...
|6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers|
...-------------+----------------+-----------------------+-...
6LoWPAN, TCP/UDP, App payload:
...+-------------------------+------------+-----------+
|Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload|
...------------------------+------------+-----------+
The frame comes from the source IPv6 address 2001:0db8:ac10:ef01::ff:fe00:1206.
The source prefix 2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3.
The frame is delivered in direct range from the gateway which has source NodeID = 1.
The Interface Identifier (IID) ff:fe00:1206 is recognised as a link-layer-derived address
and is compressed to the 16 bit value 0x1206.
The frame is sent to the destination IPv6 address 2001:0db8:27ef:42ca::ff:fe00:0004.
The destination prefix 2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2.
The Interface Identifier (IID) ff:fe00:0004 is recognised as a link-layer-derived address.
Thanks to the link-layer-derived addressing rules, the sender knows that this is to be sent
to G.9959 NodeID = 4; targeting the IPv6 interface instance number 0 (the default).
To reach the 6LoWPAN stack of the G.9959 node, (skipping the G.9959 header fields) the first octet must be the 6LoWPAN Command Class (0x4F).
0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-...
| 0x4F |
+-+-+-+-+-+-+-+-+-...
The Dispatch header bits '011' advertises a compressed IPv6 header to follow.
0 1
0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1
+-+-+-+-+-+-+-+-+-+-+-+-...
The following bits encode the following:
TF = '11' : Traffic Class and Flow Label are elided.
NH = '1' : Next Header is elided
HLIM = '10' : Hop limit is 64
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
CID = '1' : CI data follows the DAM field
SAC = '1' : Src addr uses stateful, context-based compression
SAM = '10' : Combine src CID and 16 bits to link-layer-derived addr
M = '0' : Dest addr is not a multicast addr
DAC = '1' : Dest addr uses stateful, context-based compression
DAM = '11' : Combine dest CID and dest NodeID to link-layer-derived addr
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 0 1|1 1 1 0 0 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Address compression context identifiers:
SCI = 0x3
DCI = 0x2
2 3
4 5 6 7 8 9 0 1
...+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 |
...+-+-+-+-+-+-+-+-...
IPv6 header fields:
(skipping "version" field)
(skipping "Traffic Class")
(skipping "flow label")
(skipping "payload length")
IPv6 header address fields:
SrcIP = 0x1206 : 16 LS bits of link-layer-derived address to combine with SCI
(skipping DestIP ) - completely reconstructed from Dest NodeID and DCI
2 3 4
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 | 0x12 | 0x06 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Hext header encoding for the UDP header:
Dispatch = '11110': Next Header dispatch code for UDP header
C = '0' : 16 bit checksupm carried inline
P = '00' : both src port and dest Port are carried in-line.
4 5
8 9 0 1 2 3 4 5
...+-+-+-+-+-+-+-+-...
|1 1 1 1 0|0|0 0|
...+-+-+-+-+-+-+-+-...
UDP header fields:
src Port = 0x1234
dest port = 0x5678
5 6 7 8
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x12 | 0x34 | 0x56 | 0x78 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
UDP header fields:
(skipping "length")
checksum = .... (actual checksum value depends on
the actual UDP payload)
1
8 9 0
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| (UDP checksum) |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Add your own UDP payload here...
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 layer but that specific mesh-under routing protocols are not
within the scope of this doc. within the scope of this doc.
o Clarified that RFC6282 IPv6 Header Compression MUST be supported. o Clarified that RFC6282 IPv6 Header Compression MUST be supported.
o Clarified the text of section 5.4 on the use of RFC6775 address o Clarified the text of section 5.4 on the use of RFC6775 address
registration in mesh-under networks. registration in mesh-under networks.
o Split 5.4.2 into multiple paragraphs. o Split 5.4.2 into multiple paragraphs.
A.2. Changes since -01 B.2. Changes since -01
o Added this Change Log o Added this Change Log
o Editorial nits. o Editorial nits.
o Made IPv6 Header Compression mandatory. Therefore, the Dispatch o Made IPv6 Header Compression mandatory. Therefore, the Dispatch
value "01 000001 - Uncompressed IPv6 Addresses" was removed from value "01 000001 - Uncompressed IPv6 Addresses" was removed from
figure 2. figure 2.
o Changed SHOULD to MUST: An IPv6 host SHOULD construct its link- o Changed SHOULD to MUST: An IPv6 host SHOULD construct its link-
skipping to change at page 15, line 22 skipping to change at page 18, line 40
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;
o 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.
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. 35 change blocks. 
83 lines changed or deleted 249 lines changed or added

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