draft-ietf-6lo-lowpanz-03.txt   draft-ietf-6lo-lowpanz-04.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 5, 2014 March 4, 2014 Expires: September 15, 2014 March 14, 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-03 draft-ietf-6lo-lowpanz-04
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 5, 2014. This Internet-Draft will expire on September 15, 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 32 skipping to change at page 2, line 32
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. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 14 Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 14
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 17 B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 18
B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 18 B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 18
B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 18 B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 B.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 4, line 42 skipping to change at page 4, line 42
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 This warning applies to link-layer-derived addressing as well as to
non-link-layer addressing deployments. non-link-layer-derived addressing deployments.
2.2. IPv6 Multicast support 2.2. IPv6 Multicast support
[RFC3819] recommends that IP subnetworks support (subnet-wide) [RFC3819] recommends that IP subnetworks support (subnet-wide)
multicast. G.9959 supports direct-range IPv6 multicast while subnet- multicast. G.9959 supports direct-range IPv6 multicast while subnet-
wide multicast is not supported natively by G.9959. Subnet-wide wide multicast is not supported natively by G.9959. Subnet-wide
multicast may be provided by an IP routing protocol or a mesh routing multicast may be provided by an IP routing protocol or a mesh routing
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.
skipping to change at page 6, line 42 skipping to change at page 6, line 42
An example of a complete G.9959 6LoWPAN datagram can be found in An example of a complete G.9959 6LoWPAN datagram can be found in
Appendix A. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Dispatch Type and Header Figure 1: 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. Non-6LoWPAN
protocols MUST ignore the contents following the 6LoWPAN Command protocols MUST ignore the contents following the 6LoWPAN Command
Class identifier. Class identifier.
skipping to change at page 12, line 32 skipping to change at page 12, line 32
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).
8. Acknowledgements 8. Privacy Considerations
IP addresses may be used to track devices on the Internet, which in
turn can be linked to individuals and their activities. Depending on
the application and the actual use pattern, this may be undesirable.
To impede tracking, globally unique and non-changing characteristics
of IP addresses should be avoided, e.g. by frequently changing the
global prefix and avoiding unique link-layer-derived IIDs in
addresses.
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
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
address.
While intended for central address management, DHCPv6 address
assignment also decouples the IPv6 address from the link layer
address.
It should be noted that privacy and frequently changing address
assignment comes at a cost. Non-link-layer-derived IIDs require the
use of address registration and further, non-link-layer-derived IIDs
cannot be compressed, which leads to longer datagrams and increased
link layer segmentation. Finally, frequent prefix changes
necessitate more Context Identifier updates, which not only leads to
increased traffic but also may affect the battery lifetime of
sleeping nodes.
9. Acknowledgements
Thanks to the authors of RFC 4944 and RFC 6282 and members of the Thanks to the authors of RFC 4944 and RFC 6282 and members of the
IETF 6LoWPAN working group; this document borrows extensively from IETF 6LoWPAN working group; this document borrows extensively from
their work. Thanks to Erez Ben-Tovim, Kerry Lynn, Michael their work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn,
Richardson, Tommas Jess Christensen for useful comments. Thanks to Michael Richardson, Tommas Jess Christensen for useful comments.
Carsten Bormann for extensive feedback which improved this document Thanks to Carsten Bormann for extensive feedback which improved this
significantly. document significantly.
9. References
9.1. Normative References 10. References
[EUI64] IEEE, "communicationIDELINES FOR 64-BIT GLOBAL IDENTIFIER 10.1. Normative References
(EUI-64) REGISTRATION AUTHORITY", IEEE Std http://
standards.ieee.org/regauth/oui/tutorials/EUI64.html,
November 2012.
[G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range, [G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range,
narrow-band digital radiocommunication transceivers", narrow-band digital radiocommunication transceivers",
February 2012. February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011. September 2011.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
9.2. Informative References 10.2. Informative References
[EUI64] IEEE, "GUIIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
REGISTRATION AUTHORITY", IEEE Std http://
standards.ieee.org/regauth/oui/tutorials/EUI64.html,
November 2012.
[KW03] Elsevier's AdHoc Networks Journal, ""Secure Routing in
Sensor Networks: Attacks and Countermeasures", Special
Issue on Sensor Network Applications and Protocols vol 1,
issues 2-3", , September 2003.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
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,
RFC 3819, July 2004. RFC 3819, July 2004.
skipping to change at page 14, line 21 skipping to change at page 14, line 49
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. G.9959 6LoWPAN datagram example Appendix A. G.9959 6LoWPAN datagram example
This example outlines each individual bit of a sample IPv6 UDP packet This example outlines each individual bit of a sample IPv6 UDP packet
arriving to a G.9959 node from a host in the Internet arriving to a G.9959 node from a host in the Internet via a PAN
via a PAN border router. border router.
In the G.9959 PAN, the complete frame has the following fields. In the G.9959 PAN, the complete frame has the following fields.
G.9959: G.9959:
+------+---------+----------+---+-----+----------... +------+---------+----------+---+-----+----------...
|HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID| |HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID|
+------+---------+----------+---+-----+----------+-... +------+---------+----------+---+-----+----------+-...
6LoWPAN: 6LoWPAN:
...+--------------+----------------+-----------------------... ...+--------------+----------------+-----------------------...
|6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers| |6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers|
...-------------+----------------+-----------------------+-... ...-------------+----------------+-----------------------+-...
6LoWPAN, TCP/UDP, App payload: 6LoWPAN, TCP/UDP, App payload:
...+-------------------------+------------+-----------+ ...+-------------------------+------------+-----------+
|Uncompressed IPv6 headers|TCP/UDP/ICMP|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 frame comes from the source IPv6 address
The source prefix 2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3. 2001:0db8:ac10:ef01::ff:fe00:1206. The source prefix
The frame is delivered in direct range from the gateway which has source NodeID = 1. 2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3.
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 frame is delivered in direct range from the gateway which has
The destination prefix 2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2. 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 Interface Identifier (IID) ff:fe00:0004 is recognised as a link-layer-derived address. 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.
Thanks to the link-layer-derived addressing rules, the sender knows that this is to be sent The Interface Identifier (IID) ff:fe00:0004 is recognised as a link-
to G.9959 NodeID = 4; targeting the IPv6 interface instance number 0 (the default). layer-derived address.
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). 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).
0 To reach the 6LoWPAN stack of the G.9959 node, (skipping the G.9959
0 1 2 3 4 5 6 7 8 header fields) the first octet must be the 6LoWPAN Command Class
+-+-+-+-+-+-+-+-... (0x4F).
| 0x4F |
+-+-+-+-+-+-+-+-+-...
The Dispatch header bits '011' advertises a compressed IPv6 header to follow. 0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-...
| 0x4F |
+-+-+-+-+-+-+-+-+-...
0 1 The Dispatch header bits '011' advertises a compressed IPv6 header.
0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1
+-+-+-+-+-+-+-+-+-+-+-+-...
The following bits encode the following: 0 1
0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1
+-+-+-+-+-+-+-+-+-+-+-+-...
TF = '11' : Traffic Class and Flow Label are elided. The following bits encode the first IPv6 header fields:
NH = '1' : Next Header is elided
HLIM = '10' : Hop limit is 64
0 1 TF = '11' : Traffic Class and Flow Label are elided.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 NH = '1' : Next Header is elided
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... HLIM = '10' : Hop limit is 64
| 0x4F |0 1 1 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
CID = '1' : CI data follows the DAM field 0 1
SAC = '1' : Src addr uses stateful, context-based compression 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
SAM = '10' : Combine src CID and 16 bits to link-layer-derived addr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
M = '0' : Dest addr is not a multicast addr | 0x4F |0 1 1 1 1 1 1 0|
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: CID = '1' : CI data follows the DAM field
SAC = '1' : Src addr uses stateful, context-based compression
SAM = '10' : Use src CID and 16 bits for link-layer-derived addr
M = '0' : Dest addr is not a multicast addr
DAC = '1' : Dest addr uses stateful, context-based compression
DAM = '11' : Use dest CID and dest NodeID to link-layer-derived addr
SCI = 0x3 0 1 2
DCI = 0x2 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
2 3 Address compression context identifiers:
4 5 6 7 8 9 0 1
...+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 |
...+-+-+-+-+-+-+-+-...
IPv6 header fields: SCI = 0x3
(skipping "version" field) DCI = 0x2
(skipping "Traffic Class")
(skipping "flow label")
(skipping "payload length")
IPv6 header address fields: 2 3
4 5 6 7 8 9 0 1
...+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 |
...+-+-+-+-+-+-+-+-...
SrcIP = 0x1206 : 16 LS bits of link-layer-derived address to combine with SCI IPv6 header fields:
(skipping DestIP ) - completely reconstructed from Dest NodeID and DCI (skipping "version" field)
(skipping "Traffic Class")
(skipping "flow label")
(skipping "payload length")
2 3 4 IPv6 header address fields:
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: SrcIP = 0x1206 : Use SCI and 16 LS bits of link-layer-derived address
Dispatch = '11110': Next Header dispatch code for UDP header (skipping DestIP ) - completely reconstructed from Dest NodeID and DCI
C = '0' : 16 bit checksupm carried inline
P = '00' : both src port and dest Port are carried in-line.
4 5 2 3 4
8 9 0 1 2 3 4 5 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
|1 1 1 1 0|0|0 0| | 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: UDP header fields:
src Port = 0x1234 src Port = 0x1234
dest port = 0x5678 dest port = 0x5678
5 6 7 8 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 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 | | 0x12 | 0x34 | 0x56 | 0x78 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..
UDP header fields:
(skipping "length") (skipping "length")
checksum = .... (actual checksum value depends on checksum = .... (actual checksum value depends on
the actual UDP payload) the actual UDP payload)
1 1
8 9 0 8 9 0
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| (UDP checksum) | | (UDP checksum) |
skipping to change at page 19, line 5 skipping to change at page 19, line 44
B.3. Changes since -02 B.3. Changes since -02
o Editorial nits. o Editorial nits.
o Moved text to the right section so that it does not prohibit DAD o Moved text to the right section so that it does not prohibit DAD
for Route-Over deployments. for Route-Over deployments.
o Introduced RA m flag support so that nodes may be instructed to o Introduced RA m flag support so that nodes may be instructed to
use DHCPv6 for centralized address assignment. use DHCPv6 for centralized address assignment.
o Added example appendix: Complete G.9959 6LoWPAN datagram
composition with CID-based header compression
B.4. Changes since -03
o Corrected error in 6LoWPAN datagram example appendix: 64 hop limit
in comment => also 64 hop limit in actual frame format.
o Added section "Privacy Considerations"
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. 48 change blocks. 
131 lines changed or deleted 177 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/