One document matched: draft-brandt-6man-lowpanz-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-brandt-6man-lowpanz-00" ipr="trust200902">
<front>
<title abbrev="IPv6 over G.9959">Transmission of IPv6 packets over ITU-T
G.9959 Networks</title>
<author fullname="Anders Brandt" initials="A." surname="Brandt">
<organization>Sigma Designs</organization>
<address>
<postal>
<street>Emdrupvej 26A, 1.</street>
<city>Copenhagen O</city>
<code>2100</code>
<region/>
<country>Denmark</country>
</postal>
<phone/>
<facsimile/>
<email>anders_brandt@sigmadesigns.com</email>
</address>
</author>
<author fullname="Jakob Buron" initials="J." surname="Buron">
<organization>Sigma Designs</organization>
<address>
<postal>
<street>Emdrupvej 26A, 1.</street>
<city>Copenhagen O</city>
<code>2100</code>
<region/>
<country>Denmark</country>
</postal>
<phone/>
<facsimile/>
<email>jakob_buron@sigmadesigns.com</email>
</address>
</author>
<date day="8" month="February" year="2013"/>
<area>Internet Area</area>
<workgroup>IPv6 Maintenance WG</workgroup>
<keyword>Z-Wave</keyword>
<keyword>IP over foo</keyword>
<abstract>
<t>This 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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119"/>.</t>
</note>
</front>
<middle>
<section title="Author's notes">
<t>This chapter MUST be deleted before going for last call.</t>
<section title="Reader's guidance">
<t>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:</t>
<t><list style="symbols">
<t>EUI-64 link-layer addresses</t>
<t>Fragmentation layer</t>
<t>Mesh routing</t>
</list></t>
<t>The 16-bit short addresses of 802.15.4 have been changed to 8-bit
G.9959 NodeIDs.</t>
</section>
</section>
<section title="Introduction">
<t>The ITU-T G.9959 recommendation <xref target="G.9959"/> targets
low-power Personal Area Networks (PANs). This document defines the frame
format for transmission of IPv6 <xref target="RFC2460"/> packets as well
as the formation of IPv6 link-local addresses and statelessly
autoconfigured IPv6 addresses on G.9959 networks.</t>
<t>The general approach is to adapt elements of the 6LoWPAN <xref
target="RFC4944"/> specification to G.9959 networks. G.9959 provides a
Segmentation and Reassembly (SAR) layer for transmission of datagrams
larger than the G.9959 MAC PDU.</t>
<t>In addition to IPv6 application communication, the frame format
defined in this specification may be used by IPv6 routing protocols such
as <xref target="RFC6550">RPL</xref> or <xref
target="P2P-RPL">P2P-RPL</xref> to implement IPv6 routing over G.9959
networks.</t>
<t>G.9959 networks may implement mesh routing between nodes below the IP
layer. Mesh routing is out of scope of this document.</t>
<section title="Terms used">
<t>AES: Advanced Encryption Scheme</t>
<t>EUI-64: Extended Unique Identifier</t>
<t>HomeID: Link-Layer Network Identifier</t>
<t>IID: Interface IDentifier</t>
<t>MAC: Media Access Control</t>
<t>MTU: Maximum Transmission Unit</t>
<t>NodeID: Link-Layer Node Identifier (Short Address)</t>
<t>PAN: Personal Area Network</t>
<t>PDU: Protocol Data Unit</t>
<t>SAR: Segmentation And Reassembly</t>
<t>ULA: Unique Local Address</t>
</section>
</section>
<section title="ITU-T G.9959 parameters to use for IPv6 transport">
<t>This chapter outlines properties applying to the PHY and MAC of
G.9959 and how to use these for IPv6 transport.</t>
<section title="Addressing mode">
<t>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.</t>
<t>An IPv6 host SHOULD construct its link-local IPv6 address and
routable IPv6 addresses from the G.9959 NodeID in order to facilitate
IP header compression as described in <xref target="RFC6282"/>.</t>
<t>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.</t>
</section>
<section title="IPv6 Multicast support">
<t><xref target="RFC3819"/> 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. Mesh routing
is out of scope of this document.</t>
<t>IPv6 multicast packets MUST be carried via G.9959 broadcast.</t>
<t>As per <xref target="G.9959"/>, this is accomplished as
follows:</t>
<t><list style="numbers">
<t>The destination HomeID of the G.9959 MAC PDU MUST be the HomeID
of the logical network</t>
<t>The destination NodeID of the G.9959 MAC PDU MUST be the
broadcast NodeID (0xff)</t>
</list>G.9959 broadcast MAC PDUs are only intercepted by nodes
within the logical network identified by the G.9959 HomeID.</t>
</section>
<section title="G.9959 MAC PDU size and IPv6 MTU">
<t>IPv6 packets MUST use G.9959 transmission profiles which support
MAC PDU payload sizes of 150 bytes or higher, e.g. the R3 profile.</t>
<t><xref target="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. G.9959
link-layer security imposes an overhead, which in the extreme case
leaves 130 octets available.</t>
<t>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 <xref target="RFC6282"/> improves the chances that
a short IPv6 packet can fit into a single G.9959 frame.</t>
</section>
<section title="Transmission status indications">
<t>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. The feature may
however introduce challenges to existing TCP rate control algorithms
and it may mask problematic links from IP routing protocols.</t>
<section title="IPv6 Socket interface considerations">
<t>An IPv6 socket implementation communicating over G.9959 MUST have
access to status indications such as link-layer delivery
confirmation and Ack timeout from the MAC layer. If there is a mesh
routing layer below the LoWPAN layer, the IPv6 socket implementation
MUST have access to status indications such as delivery confirmation
and Ack timeout from the mesh routing layer. This will allow the
IPv6 socket implementation to adjust its transmissions to the
available bandwidth of the G.9959 network; transmitting a new IPv6
packet only when it positively knows that the previous transmission
ended (with fail or success).</t>
</section>
<section title="IPv6 Routing protocol interface considerations">
<t>An IPv6 routing stack communicating over G.9959 MUST have access
to delivery status indications such as link-layer delivery
confirmation and Ack timeout from the MAC layer. This will allow the
IP routing stack to adjust its routing decisions or alternatively
initiate route rediscovery based on status indications from the link
layer.</t>
</section>
</section>
<section title="Transmission security">
<t>G.9959 provides link-layer security based on a common network key.
Mission critical applications such as door locks and meters SHOULD
deploy additional application layer security measures for end-to-end
authentication and encryption.</t>
<t>Implementations claiming conformance with this specification MUST
enable G.9959 common network key security.</t>
</section>
</section>
<section title="LoWPAN Adaptation Layer and Frame Format">
<t>The LoWPAN encapsulation formats defined in this chapter are the
payload in the G.9959 MAC PDU or the G.9959 SAR PDU. IPv6 header
compression <xref target="RFC6282"/> MUST be supported by
implementations of this specification.</t>
<t>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 <xref target="RFC2460"/>. The LoWPAN header format is structured
the same way. Currently only payload options are defined for the LoWPAN
header format.</t>
<t>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.</t>
<section anchor="DispatchType" title="Dispatch Type and Header">
<t>The dispatch type is defined by a zero bit as the first bit and a
one bit as the second bit. The dispatch type and header are shown
here:<vspace blankLines="1"/></t>
<figure anchor="FigDispatchTypeAndHeader"
title="Dispatch Type and Header">
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LoWPAN CmdCls |0 1| Dispatch | Type-specific header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>LoWPAN CmdCls: LoWPAN Command Class identifier, <xref
target="G.9959"/>. Specifies that the following bits are a LoWPAN
encapsulated datagram. Non-LoWPAN protocols MUST ignore the contents
following the LoWPAN Command Class identifier. TBD: Explicit value to
be assigned by Z-Wave Alliance before last call of this Internet
Draft. Refer to <xref target="ZW-A_Considerations"/>.</t>
<t>Dispatch: 6-bit selector. Identifies the header type immediately
following the Dispatch Header.</t>
<t>Type-specific header: A header determined by the Dispatch
Header.</t>
<t>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.</t>
<t>Dispatch values used in this specification are compatible with the
dispatch values defined by <xref target="RFC4944"/> and <xref
target="RFC6282"/>.</t>
<t><vspace blankLines="1"/></t>
<figure anchor="FigDispatchValueBitPattern"
title="Dispatch Value Bit Pattern">
<artwork><![CDATA[+------------+------------------------------------------+-----------+
| Pattern | Header Type | Reference |
+------------+------------------------------------------+-----------+
| 01 000000 | ESC - Dispatch octet #2 follows | [RFC6282] |
| 01 000001 | IPv6 - Uncompressed IPv6 Addresses| [RFC4944] |
| ... | reserved - Defined or reserved | [RFC4944] |
| 01 1xxxxx | LoWPAN_IPHC - LoWPAN_IPHC compressed IPv6| [RFC6282] |
| 1x xxxxxx | reserved - Defined or reserved | [RFC4944] |
+------------+------------------------------------------+-----------+]]></artwork>
</figure>
<t>IPv6: Specifies that the following header is an uncompressed IPv6
header.</t>
<t>ESC: Specifies that the following header is a single 8-bit field
for an additional Dispatch value. It allows support for Dispatch
values larger than 63. Note: <xref target="RFC4944"/> assigns the
value 01 111111 for ESC. That assignment was deprecated by <xref
target="RFC6282"/>.</t>
<t>LoWPAN_IPHC: IPv6 Header Compression. Refer to <xref
target="RFC6282"/>.</t>
</section>
</section>
<section anchor="LowpanAddressing" title="LoWPAN addressing">
<t>IPv6 addresses are derived from link-layer address information to
save memory in devices and to facilitate efficient IP header
compression.</t>
<t>A G.9959 NodeID is 8 bits in length. NodeIDs are mapped into the
restricted space of IEEE EUI-64 addresses by setting the middle 16 bits
to 0xfffe, the bottom 8 bits to the NodeID, and all other bits to zero.
As a result, an Interface Identifier (IID) generated from a NodeID has
the form:<vspace blankLines="1"/></t>
<figure>
<artwork><![CDATA[ IID = 0000:00ff:fe00:00XX]]></artwork>
</figure>
<t>where XX carries the G.9959 NodeID. The universal/local bit is zero
to indicate local scope.</t>
<t/>
<t>This mapping differs from that presented in Appendix A of [RFC4291].
Using the restricted space ensures that there is no overlap with IIDs
generated from unrestricted IEEE EUI-64 addresses. Also, including
0xfffe in the middle of the IID helps avoid overlap with other locally
managed IIDs. Further, the mapping enables efficient IP Header
Compression as per <xref target="RFC6282"/>.</t>
<section anchor="StatelessAddressAutoconfiguration"
title="Stateless Address Autoconfiguration of routable IPv6 addresses">
<t>The IID defined above MUST be used whether autoconfiguring a ULA
IPv6 address <xref target="RFC4193"/> or a globally routable IPv6
address <xref target="RFC3587"/> in G.9959 subnets.</t>
</section>
<section anchor="ChapterIPv6_LinkLocalAddress"
title="IPv6 Link Local Address">
<t>The IPv6 link-local address <xref target="RFC4291"/> for a G.9959
interface is formed by appending the IID to the IPv6 link local prefix
FE80::/64.</t>
<t>The "Universal/Local" (U/L) bit MUST be set to zero in keeping with
the fact that this is not a globally unique value <xref
target="EUI64"/>.</t>
<t>The resulting link local address is formed as follows:<vspace
blankLines="1"/></t>
<figure anchor="FigIPv6_LinkLocalAddress"
title="IPv6 Link Local Address">
<artwork><![CDATA[ 10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier (IID) |
+----------+-----------------------+----------------------------+]]></artwork>
</figure>
<t><vspace blankLines="1"/></t>
</section>
<section anchor="UnicastAddressMapping" title="Unicast Address Mapping">
<t>The address resolution procedure for mapping IPv6 unicast addresses
into G.9959 link-layer addresses follows the general description in
Section 7.2 of <xref target="RFC4861"/>. The Source/Target Link-layer
Address option MUST have the following form when the link layer is
G.9959.<vspace blankLines="1"/></t>
<figure anchor="FigIPv6_UnicastAddressMapping"
title="IPv6 Unicast Address Mapping">
<artwork><![CDATA[ 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HomeID1 (MS) | HomeID2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HomeID3 | HomeID4 (LS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><vspace blankLines="1"/>Option fields:</t>
<t>Type: The value 1 signifies the Source Link-layer address. The
value 2 signifies the Destination Link-layer address.</t>
<t>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.</t>
<t>HomeID: This is the G.9959 HomeID the actual interface currently
responds to. The link-layer address may change if the interface joins
another network at a later time.</t>
<t>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.</t>
</section>
</section>
<section anchor="HeaderCompression" title="Header Compression">
<t>IPv6 header fields SHOULD be compressed. If IPv6 header compression
is used, it MUST be according to <xref target="RFC6282"/>. This section
will simply identify substitutions that should be made when interpreting
the text of [RFC6282].</t>
<t>In general the following substitutions should be made:</t>
<t><list style="symbols">
<t>Replace "802.15.4" with "G.9959"</t>
<t>Replace "802.15.4 short address" with "G.9959 NodeID"</t>
<t>Replace "802.15.4 PAN ID" with "G.9959 HomeID"</t>
</list> When a 16-bit address is called for (i.e., an IEEE 802.15.4
"short address") it MUST be formed by padding the G.9959 NodeID to the
left with zeros:</t>
<figure>
<artwork><![CDATA[ 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><vspace blankLines="1"/>64 bit 802.15.4 address details should be
ignored. This document only specifies the use of short addresses.</t>
</section>
<section anchor="IANA_Considerations" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="ZW-A_Considerations"
title="Z-Wave Allliance Considerations">
<t>This document requests that the Z-Wave Alliance assigns a Command
Class identifier for the LoWPAN Command Class; refer to <xref
target="DispatchType"/>.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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 <xref
target="RFC3756"/>. 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.</t>
<t>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).</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to the authors of RFC 4944 and RFC6282 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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4291"?>
<?rfc include="reference.RFC.4944"?>
<?rfc include="reference.RFC.6282"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.2464"?>
<?rfc include="reference.RFC.4861"?>
<?rfc include="reference.RFC.4193"?>
<?rfc include="reference.RFC.3587"?>
<reference anchor="G.9959">
<front>
<title>ITU-T G.9959: Low-Power, narrowband radio for control
applications</title>
<author fullname="">
<organization/>
</author>
<date day="1" month="January" year="2012"/>
</front>
</reference>
<reference anchor="EUI64">
<front>
<title>GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION
AUTHORITY</title>
<author fullname="IEEE http:// standards.ieee.org/regauth/oui/tutorials/EUI64.html">
<organization/>
</author>
<date year=""/>
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3819"?>
<?rfc include="reference.RFC.3756"?>
<?rfc include="reference.RFC.6550"?>
<reference anchor="P2P-RPL">
<front>
<title>IETF, I-D.ietf-roll-p2p-rpl-15, Reactive Discovery of
Point-to-Point Routes in Low Power and Lossy Networks</title>
<author fullname="M. Goyal" initials="M." surname="Goyal">
<organization>University of Wisconsin</organization>
</author>
<author fullname="E. Baccelli" initials="E." surname="Baccelli">
<organization>INRIA</organization>
</author>
<author fullname="M. Philipp" initials="M." surname="Philipp">
<organization>INRIA</organization>
</author>
<author fullname="A. Brandt" initials="A." surname="Brandt">
<organization>Sigma Designs</organization>
</author>
<author fullname="J. Martocci" initials="J." surname="Martocci">
<organization>Johnson Controls</organization>
</author>
<date day="12" month="December" year="2012"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:36:32 |