draft-ietf-6lo-lowpanz-04.txt   draft-ietf-6lo-lowpanz-05.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: September 15, 2014 March 14, 2014 Expires: November 6, 2014 May 5, 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-04 draft-ietf-6lo-lowpanz-05
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 September 15, 2014. This Internet-Draft will expire on November 6, 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . 4
2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 4 2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 4
2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 4 2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 5
2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 5 2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 6
2.4. Transmission status indications . . . . . . . . . . . . . 5 2.4. Transmission status indications . . . . . . . . . . . . . 6
2.5. Transmission security . . . . . . . . . . . . . . . . . . 5 2.5. Transmission security . . . . . . . . . . . . . . . . . . 6
3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 6 3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 7
3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 6 3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 7
4. 6LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . 7 4. 6LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . 8
4.1. Stateless Address Autoconfiguration of routable IPv6 4.1. Stateless Address Autoconfiguration of routable IPv6
addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9
4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 8 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9
4.4. On the use of Neighbor Discovery technologies . . . . . . 9 4.4. On the use of Neighbor Discovery technologies . . . . . . 10
4.4.1. Prefix and CID management (Route-over) . . . . . . . 9 4.4.1. Prefix and CID management (Route-over) . . . . . . . 10
4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 10 4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 11
5. Header Compression . . . . . . . . . . . . . . . . . . . . . 11 5. Header Compression . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 14 Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 15
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 18 B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 19
B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 18 B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 19
B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 19 B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 20
B.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 19 B.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 25 skipping to change at page 3, line 25
Alternatively, IPv6 addresses may be assigned centrally via DHCP, Alternatively, IPv6 addresses may be assigned centrally via DHCP,
leading to a "non-link-layer-derived IPv6 address". Address leading to a "non-link-layer-derived IPv6 address". Address
registration is only needed in certain cases. 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. Mesh-under
protocol specifications are out of scope of this document. and route-over routing 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 6LoWPAN: IPv6-based Low-power Personal Area Network
ABR: Authoritative Border Router ([RFC6775]) ABR: Authoritative Border Router ([RFC6775])
Ack: Acknowedgement
AES: Advanced Encryption Scheme AES: Advanced Encryption Scheme
EUI-64: Extended Unique Identifier CID: Context Identifier ([RFC6775])
DAD: Duplicate Address Detection ([RFC6775])
DHCPv6: Dynamic Host Configuration Protocol for IPv6 ([RFC3315])
EUI-64: Extended Unique Identifier ([EUI64])
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
layer address information
MAC: Media Access Control MAC: Media Access Control
Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer
MTU: Maximum Transmission Unit MTU: Maximum Transmission Unit
NodeID: G.9959 Link-Layer Node Identifier (Short Address) ND: Neighbor discovery ([RFC4861], [RFC6775])
NodeID: G.9959 Link-Layer Node Identifier
Non-link-layer-derived address: IPv6 Address assigned by a managed
process, e.g. DHCPv6.
P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and
Lossy Networks ([RFC6997])
PAN: Personal Area Network PAN: Personal Area Network
PDU: Protocol Data Unit PDU: Protocol Data Unit
SAR: Segmentation And Reassembly RA: Router Advertisement ([RFC4861], [RFC6775])
ULA: Unique Local Address
Route-over: Forwarding via IP routing above the 6LoWPAN layer
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
([RFC6550])
SAR: G.9959 Segmentation And Reassembly
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 logical identifier is allocated. NodeIDs are unique within the network
network identified by the HomeID. The logical network identified by identified by the HomeID. The G.9959 network controller function
the HomeID maps directly to an IPv6 subnet identified by one or more SHOULD be integrated in the ABR. The G.9959 HomeID represents an
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. If the M flag is not construction of routable IPv6 addresses. The M flag MUST be
supported, link-layer-derived addressing MUST be used. If the M flag interpreted as defined in Figure 1.
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 | M Flag | M flag | Required node behavior |
[RFC6775]. | support| value | |
+--------+--------+---------------------------------------------+
| No |(ignore)| Node MUST use link-layer-derived addressing |
+--------+--------+---------------------------------------------+
| Yes | 0 | Node MUST use link-layer-derived addressing |
| +--------+---------------------------------------------+
| | 1 | Node MUST use DHCPv6 based addressing and |
| | | Node MUST comply fully with [RFC6775] |
+--------+--------+---------------------------------------------+
Figure 1: RA M flag support and interpretation
A node that uses DHCPv6 based addressing MUST comply fully with the
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 logical network uniqueness is limited by the lifetime of the network membership.
membership. This can be cut short by a mishap occurring to the This can be cut short by a mishap occurring to the network
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 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 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)
skipping to change at page 5, line 10 skipping to change at page 6, line 8
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.
As per [G.9959], this is accomplished as follows: As per [G.9959], this is accomplished as follows:
1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID 1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID
of the logical network of the network
2. The destination NodeID of the G.9959 MAC PDU MUST be the 2. The destination NodeID of the G.9959 MAC PDU MUST be the
broadcast NodeID (0xff) broadcast NodeID (0xff)
G.9959 broadcast MAC PDUs are only intercepted by nodes within the G.9959 broadcast MAC PDUs are only intercepted by nodes within the
logical 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 use G.9959 transmission profiles which support MAC IPv6 packets MUST be transmitted using G.9959 transmission profile R3
PDU payload sizes of 150 bytes or higher, i.e. profile R3 or higher. or higher.
(G.9959 profiles R1 and R2 only support MPDU payloads around 40 bytes
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.
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. Longer 6LoWPAN datagrams will G.9959 Segmentation and Reassembly (SAR). Longer 6LoWPAN datagrams
lead to the transmission of multiple G.9959 PDUs. will lead to the transmission of multiple G.9959 PDUs.
2.4. Transmission status indications 2.4. Transmission status indications
The G.9959 MAC layer provides native acknowledgement and The G.9959 MAC layer provides native acknowledgement and
retransmission of MAC PDUs. The G.9959 SAR layer does the same for retransmission of MAC PDUs. The G.9959 SAR layer does the same for
larger datagrams. A mesh routing layer may provide a similar feature larger datagrams. A mesh routing layer may provide a similar feature
for routed communication. An IPv6 routing stack communicating over for routed communication. An IPv6 routing stack communicating over
G.9959 may utilize link-layer status indications such as delivery G.9959 may utilize link-layer status indications such as delivery
confirmation and Ack timeout from the MAC layer. confirmation and Ack timeout from the MAC layer.
skipping to change at page 6, line 45 skipping to change at page 7, line 41
3.1. Dispatch Header 3.1. Dispatch Header
The dispatch header is shown below: The dispatch header is shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6LoWPAN CmdCls| Dispatch | Type-specific header | | 6LoWPAN CmdCls| Dispatch | Type-specific header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: 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 specifies that the
following bits are a 6LoWPAN encapsulated datagram. Non-6LoWPAN following bits are a 6LoWPAN encapsulated datagram. 6LoWPAN protocols
protocols MUST ignore the contents following the 6LoWPAN Command MUST ignore the G.9959 frame if the 6LoWPAN Command Class identifier
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 7, line 29 skipping to change at page 8, line 24
Dispatch values used in this specification are compatible with the Dispatch values used in this specification are compatible with the
dispatch values defined by [RFC4944] and [RFC6282]. dispatch values defined by [RFC4944] and [RFC6282].
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| 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 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 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 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 3: 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
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.
The method of constructing IIDs from the link-layer address obviously The method of constructing IIDs from the link-layer address obviously
does not support addresses assigned or constructed by other means. A does not support addresses assigned or constructed by other means. A
node MUST NOT compute the NodeID from the IID if the first 6 bytes of node MUST NOT compute the NodeID from the IID if the first 6 bytes of
the IID do not comply with the format defined in Figure 3. In that the IID do not comply with the format defined in Figure 4. In that
case, the address resolution mechanisms of RFC 6775 apply. case, the address resolution mechanisms of 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.
4.2. IPv6 Link Local Address 4.2. IPv6 Link Local Address
skipping to change at page 8, line 35 skipping to change at page 9, line 29
The "Universal/Local" (U/L) bit MUST be set to zero in keeping with The "Universal/Local" (U/L) bit MUST be set to zero in keeping with
the fact that this is not a globally unique value [EUI64]. the fact that this is not a globally unique value [EUI64].
The resulting link local address is formed as follows: The resulting link local address is formed as follows:
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier (IID) | |1111111010| (zeros) | Interface Identifier (IID) |
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
Figure 4: IPv6 Link Local Address Figure 5: IPv6 Link Local Address
4.3. Unicast Address Mapping 4.3. Unicast Address Mapping
The address resolution procedure for mapping IPv6 unicast addresses The address resolution procedure for mapping IPv6 unicast addresses
into G.9959 link-layer addresses follows the general description in into G.9959 link-layer addresses follows the general description in
Section 7.2 of [RFC4861]. The Source/Target Link-layer Address Section 7.2 of [RFC4861]. The Source/Target Link-layer Address
option MUST have the following form when the link layer is G.9959. option MUST have the following form when the link layer is G.9959.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 | | Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | NodeID | | 0x00 | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding | | Padding |
+- -+ +- -+
| (All zeros) | | (All zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 Unicast Address Mapping Figure 6: IPv6 Unicast Address Mapping
Option fields: Option fields:
Type: The value 1 signifies the Source Link-layer address. The value Type: The value 1 signifies the Source Link-layer address. The value
2 signifies the Destination Link-layer address. 2 signifies the Destination Link-layer address.
Length: This is the length of this option (including the type and Length: This is the length of this option (including the type and
length fields) in units of 8 octets. The value of this field is length fields) in units of 8 octets. The value of this field is
always 1 for G.9959 NodeIDs. always 1 for G.9959 NodeIDs.
skipping to change at page 10, line 24 skipping to change at page 11, line 24
With this exception and the specific redefinition of the RA Router With this exception and the specific redefinition of the RA Router
Lifetime value 0xFFFF (refer to Section 4.4.2.3), the text of the Lifetime value 0xFFFF (refer to Section 4.4.2.3), the text of the
following subsections is in compliance with [RFC6775]. following subsections is in compliance with [RFC6775].
4.4.2.1. Prefix assignment considerations 4.4.2.1. Prefix assignment considerations
As stated by [RFC6775], an ABR is responsible for managing As stated by [RFC6775], an ABR is responsible for managing
prefix(es). Global routable prefixes may change over time. It is prefix(es). Global routable prefixes may change over time. It is
RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to
facilitate stable site-local application associations based on IPv6 facilitate stable site-local application associations based on IPv6
addresses. A node MAY support the M flag of the RA message. If the addresses. A node MAY support the M flag of the RA message. This
M flag is not supported, link-layer-derived addressing MUST be used. influences the way IPv6 addresses are assigned. Refer to Section 2.1
If the M flag is supported, link-layer-derived addressing MUST be for details.
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.
One or more prefixes and corresponding Context IDs MUST be assigned One or more prefixes and corresponding Context IDs MUST be assigned
during initial node inclusion. during initial node inclusion.
When updating context information, a CID may have its lifetime set to When updating context information, a CID may have its lifetime set to
zero to obsolete it. The CID MUST NOT be reused immediately; rather zero to obsolete it. The CID MUST NOT be reused immediately; rather
skipping to change at page 12, line 8 skipping to change at page 12, line 50
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
The method of derivation of Interface Identifiers from 8-bit NodeIDs The method of derivation of Interface Identifiers from 8-bit NodeIDs
preserves uniqueness within the logical network. However, there is preserves uniqueness within the network. However, there is no
no protection from duplication through forgery. Neighbor Discovery protection from duplication through forgery. Neighbor Discovery in
in G.9959 links may be susceptible to threats as detailed in G.9959 links may be susceptible to threats as detailed in [RFC3756].
[RFC3756]. G.9959 networks may feature mesh routing. This implies G.9959 networks may feature mesh routing. This implies additional
additional threats due to ad hoc routing as per [KW03]. G.9959 threats due to ad hoc routing as per [KW03]. G.9959 provides
provides capability for link-layer security. G.9959 nodes MUST use capability for link-layer security. G.9959 nodes MUST use link-layer
link-layer security with a shared key. Doing so will alleviate the security with a shared key. Doing so will alleviate the majority of
majority of threats stated above. A sizeable portion of G.9959 threats stated above. A sizeable portion of G.9959 devices is
devices is expected to always communicate within their PAN (i.e., expected to always communicate within their PAN (i.e., within their
within their subnet, in IPv6 terms). In response to cost and power subnet, in IPv6 terms). In response to cost and power consumption
consumption considerations, these devices will typically implement considerations, these devices will typically implement the minimum
the minimum set of features necessary. Accordingly, security for set of features necessary. Accordingly, security for such devices
such devices may rely on the mechanisms defined at the link layer by may rely on the mechanisms defined at the link layer by G.9959.
G.9959. G.9959 relies on the Advanced Encryption Standard (AES) for G.9959 relies on the Advanced Encryption Standard (AES) for
authentication and encryption of G.9959 frames and further employs authentication and encryption of G.9959 frames and further employs
challenge-response handshaking to prevent replay attacks. challenge-response handshaking to prevent replay attacks.
It is also expected that some G.9959 devices (e.g. billing and/or It is also expected that some G.9959 devices (e.g. billing and/or
safety critical products) will implement coordination or integration safety critical products) will implement coordination or integration
functions. These may communicate regularly with IPv6 peers outside functions. These may communicate regularly with IPv6 peers outside
the subnet. Such IPv6 devices are expected to secure their end-to- the subnet. Such IPv6 devices are expected to secure their end-to-
end communications with standard security mechanisms (e.g., IPsec, end communications with standard security mechanisms (e.g., IPsec,
TLS, etc). TLS, etc).
skipping to change at page 12, line 50 skipping to change at page 13, line 44
addresses. addresses.
Some link layers use a 48-bit or a 64-bit link layer address which Some link layers use a 48-bit or a 64-bit link layer address which
uniquely identifies the node on a global scale regardless of global uniquely identifies the node on a global scale regardless of global
prefix changes. The risk of exposing a G.9959 device from its link- prefix changes. The risk of exposing a G.9959 device from its link-
layer-derived IID is limited because of the short 8-bit link layer layer-derived IID is limited because of the short 8-bit link layer
address. address.
While intended for central address management, DHCPv6 address While intended for central address management, DHCPv6 address
assignment also decouples the IPv6 address from the link layer assignment also decouples the IPv6 address from the link layer
address. address. Addresses may be made dynamic by the use of a short DHCP
lease period and an assignment policy which makes the DHCP server
hand out a fresh IP address every time.
It should be noted that privacy and frequently changing address It should be noted that privacy and frequently changing address
assignment comes at a cost. Non-link-layer-derived IIDs require the assignment comes at a cost. Non-link-layer-derived IIDs require the
use of address registration and further, non-link-layer-derived IIDs use of address registration and further, non-link-layer-derived IIDs
cannot be compressed, which leads to longer datagrams and increased cannot be compressed, which leads to longer datagrams and increased
link layer segmentation. Finally, frequent prefix changes link layer segmentation. Finally, frequent prefix changes
necessitate more Context Identifier updates, which not only leads to necessitate more Context Identifier updates, which not only leads to
increased traffic but also may affect the battery lifetime of increased traffic but also may affect the battery lifetime of
sleeping nodes. sleeping nodes.
skipping to change at page 14, line 26 skipping to change at page 15, line 22
[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,
issues 2-3", , September 2003. issues 2-3", , September 2003.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003. Unicast Address Format", RFC 3587, August 2003.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May Discovery (ND) Trust Models and Threats", RFC 3756, May
2004. 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
skipping to change at page 16, line 41 skipping to change at page 17, line 41
CID = '1' : CI data follows the DAM field CID = '1' : CI data follows the DAM field
SAC = '1' : Src addr uses stateful, context-based compression SAC = '1' : Src addr uses stateful, context-based compression
SAM = '10' : Use src CID and 16 bits for link-layer-derived addr SAM = '10' : Use src CID and 16 bits for link-layer-derived addr
M = '0' : Dest addr is not a multicast addr M = '0' : Dest addr is not a multicast addr
DAC = '1' : Dest addr uses stateful, context-based compression DAC = '1' : Dest addr uses stateful, context-based compression
DAM = '11' : Use dest CID and dest NodeID to link-layer-derived addr DAM = '11' : Use dest CID and dest NodeID to link-layer-derived addr
0 1 2 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 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| | 0x4F |0 1 1 1 1 1 1 0|1 1 1 0 0 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Address compression context identifiers: Address compression context identifiers:
SCI = 0x3 SCI = 0x3
DCI = 0x2 DCI = 0x2
2 3 2 3
4 5 6 7 8 9 0 1 4 5 6 7 8 9 0 1
...+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-...
skipping to change at page 17, line 34 skipping to change at page 18, line 34
SrcIP = 0x1206 : Use SCI and 16 LS bits of link-layer-derived address SrcIP = 0x1206 : Use SCI and 16 LS bits of link-layer-derived address
(skipping DestIP ) - completely reconstructed from Dest NodeID and DCI (skipping DestIP ) - completely reconstructed from Dest NodeID and DCI
2 3 4 2 3 4
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 | 0x12 | 0x06 | | 0x3 | 0x2 | 0x12 | 0x06 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Hext header encoding for the UDP header: Next header encoding for the UDP header:
Dispatch = '11110': Next Header dispatch code for UDP header Dispatch = '11110': Next Header dispatch code for UDP header
C = '0' : 16 bit checksupm carried inline C = '0' : 16 bit checksum carried inline
P = '00' : both src port and dest Port are carried in-line. P = '00' : Both src port and dest Port are carried in-line.
4 5 4 5
8 9 0 1 2 3 4 5 8 9 0 1 2 3 4 5
...+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-...
|1 1 1 1 0|0|0 0| |1 1 1 1 0|0|0 0|
...+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-...
UDP header fields: UDP header fields:
src Port = 0x1234 src Port = 0x1234
 End of changes. 34 change blocks. 
90 lines changed or deleted 137 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/