%%Title: 6lowpanのメモ
%%Created: Thu Feb 10 13:33:06 JST 2005
%%Updated:
802.15.4 Standard
==================
6.4.1 PHY Constants
aMaxPHYPacketSize : 127 octets
the maximum PSDU size the PHY shall be able to receive.
5.4.3 Frame structure
PHY layer
4 1 1 (octet)
+---+---+---+---+---+---+----...............................----+
| Preamble |SFD|Frm| MPDU |
| Sequence | |Len| |
+---+---+---+---+---+---+----...............................----+
| | | |
|<------ SHR ------>|PHR|<--------------- PSDU ---------------->|
| |
|<---------------------------- PPDU --------------------------->|
MPDU: MAC Protocol Data Unit
SFD : Start of Frame Delimiter
Frmlen: Frame length (7bits) + Reserved (1bit)
SHR : Synchronization Header
PHR : PHY Header
PSDU: PHY Service Data Unit (PHY payload)
PPDU: PHY Protocol Data Unit
5.4.3.1 Beacon frame
MAC sublayer
2 1 4 to 20 2 k m n 2 (octet)
+---+---+---+----...----+---+---+-.....-+-.....-+-.....-+---+---+
|Frame |Seq|Adressing | SFS | GTS |Pending|Beacon | FCS |
|Control|Num| Fields | |Fields |AddrFld|Payload| |
+---+---+---+----...----+---+---+-.....-+-.....-+-.....-+---+---+
| | | |
|<-------- MHR -------->|<----------- MSDU ------------>|<-MFR->|
| |
|<---------------------------- MPDU --------------------------->|
SFS : Superframe Specification
FCS : Frame Check Sequence
MHR : MAC Header
MSDU: MAC Service Data Unit
MFR : MAC Footer
5.4.3.2 Data frame
MAC sublayer
2 1 4 to 20 n 2 (octet)
+---+---+---+----...----+----.......................----+---+---+
|Frame |Seq|Adressing | Data Payload | FCS |
|Control|Num| Fields | | |
+---+---+---+----...----+----.......................----+---+---+
| | | |
|<-------- MHR -------->|<----------- MSDU ------------>|<-MFR->|
| |
|<---------------------------- MPDU --------------------------->|
MSDU: MAC Service Data Unit
MHR : MAC Header
MFR : MAC Footer
FCS : Frame Check Sequence
5.4.3.3 Acknowledgment frame
MAC sublayer
2 1 2 (octet)
+---+---+---+---+---+
|Frame |Seq| FCS |
|Control|Num| |
+---+---+---+---+---+
| | |
|<-- MHR -->|<-MFR->|
| |
|<------ MPDU ----->|
MHR : MAC Header
MFR : MAC Footer
FCS : Frame Check Sequence
5.4.3.4 MAC command frame
MAC sublayer
2 1 4 to 20 n 2 (octet)
+---+---+---+----...----+---+----...................----+---+---+
|Frame |Seq|Adressing |Cmd| Command Payload | FCS |
|Control|Num| Fields |Typ| | |
+---+---+---+----...----+---+----...................----+---+---+
| | | |
|<-------- MHR -------->|<----------- MSDU ------------>|<-MFR->|
| |
|<---------------------------- MPDU --------------------------->|
MSDU: MAC Service Data Unit
MHR : MAC Header
MFR : MAC Footer
FCS : Frame Check Sequence
7.2.1 MAC frame format
Frame Control
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 (bit)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Frame |Sec|Frm|Ack|Int| Reserved |DstAdr | |SrcAdr |
| Type | |Pnd|Req|PAN| | mode | | mode |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Frame Type : 001 data
Sec(Security enabled): 0 no security at the MAC sublayer
FrmPnd(Frame pending): 0 the sender won't send any more data
AckReq(Acknowledgment request):
0 the recipient don't need to send an ack.
IntPAN(Intra-PAN) : 0 if both dst and src address are present,
then both PAN identifiers are present.
1 if both dst and src address are present,
then source PAN identifiers are NOT present.
DstAdr mode(Destination addressing mode):
SrcAdr mode(Source addressing mode):
00 PAN identifier and the address field are not present
01 Reserved
10 16 bit short address
11 64 bit short address
Addressing Fields
2 4 or 8 2 4 or 8 (octet)
+---+---+---------------+---+---+---------------+
|DstPAN | Destination |SrcPAN | Source |
| Ident | Address | Ident | Address |
+-------+---------------+-------+---------------+
Addressing Fields Length
Destination PAN Identifier: 0 or 2
Source PAN Identifier : 0 or 2
Destination Address : 0 or 2 or 8
Source Address : 0 or 2 or 8
IntPAN DstMode SrcMode AddrFldLen
------ ------- ------- ----------
0 00 00 4
0 00 10 4
0 00 11 10
0 10 10 8
0 10 11 14
0 11 10 14
0 11 11 20
1 00 00 4
1 00 10 4
1 00 11 10
1 10 10 8
1 10 11 14
1 11 10 14
1 11 11 20
IPv6 over 802.15.4
==================
MTU 1280
127 aMaxPHYPacketSize
25 aMaxFrameOverhead
21 maximum L2 security overhead (21 AES-CCM-128, 13 AES-CCM-64, 9 AES-CCM-32)
---
81 minimum payload length
127 aMaxPHYPacketSize
9 aMaxFrameOverhead
---
118 minimum payload length
ESP
SPI = 4
SEQ = 4
padlen = 1
next header = 1
ICV = 0 (could be)
ICV = 96 (but MUST HMAC-SHA1-96)
4.1 Link Fragmentation
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF|prot_type|M| IPv6 packet (or Final Destination) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Unfragmented encapsulation header format
The address fields encoded by "HC1 encoding" are interpreted as
follows:
PI: Prefix included in-line
PC: Prefix compressed (link-local prefix assumed)
II: Interface identifier included in-line
IC: Interface identifier compressed (derived from link-layer
address)
The "HC1 encoding" is shown below (starting with bit 0 and ending at
bit 7):
IPv6 source address (bits 0 and 1):
00: PI, II
01: PI, IC
10: PC, II
11: PC, IC
IPv6 destination address (bits 2 and 3):
00: PI, II
01: PI, IC
10: PC, II
11: PC, IC
Traffic Class and Flow Label (bit 4):
0: not compressed, full 8 bits for Traffic Class and 20 bits
for Flow Label are sent
1: Traffic Class and Flow Label are zero
Next Header (bits 5 and 6):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC1 encoding | Non-Compressed fields follow... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: LOWPAN_HC1 (common compressed header format)
01: UDP
10: ICMP
11: TCP
HC2 encoding(bit 7):
0: No more header compression bits
1: HC1 encoding immediately followed by more header compression
bits per HC2 encoding format (TBD)
7. Unicast Address Mapping
The procedure for mapping IPv6 unicast addresses into IEEE 802.15.4
link-layer addresses is described in [I-D.ietf-ipv6-2461bis]. The
Source/Target Link-layer Address option has the following form when
the link layer is IEEE 802.15.4.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- IEEE 802.15.4 -+
| |
+- -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Padding -+
| |
+- (all zeros) -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
Option fields:
Type:
1: for Source Link-layer address.
2: for Target Link-layer address.
Length: 2 (in units of 8 octets).
IEEE 802.15.4 Address: The 64 bit IEEE 802.15.4 address, in canonical
bit order. This is the address the interface currently responds
to. This address may be different from the built-in address used
to derive the Interface Identifier, because of privacy or security
(e.g., of neighbor discovery) considerations.
6. IPv6 Link Local Address
The IPv6 link-local address [RFC3513] for an IEEE 802.15.4 interface
is formed by appending the Interface Identifier, as defined above, to
the prefix FE80::/64.
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
8.2 Non-Compressed IPv6 Fields
The non-compressed IPv6 field that MUST be always present is the Hop
Count (8 bits). This field MUST always follow the encoding fields
(e.g., "HC1 encoding" as shown in Figure 7), perhaps including other
future encoding fields). Other non-compressed fields must follow the
Hop Count as implied by the "HC1 encoding" in the exact same order as
shown above (Section 8.1): source address prefix (64 bits) and/or
interface identifier (64 bits), destination address prefix (64 bits)
and/or interface identifier (64 bits), Traffic Class (8 bits), Flow
Label (20 bits) and Next Header (8 bits). The actual next header
(e.g., UDP, TCP, ICMP, etc) follows the non-compressed fields.
Security Consideration
======================
"Security Considerations for IEEE 802.15.4 Networks"
http://www.cs.berkeley.edu/~nks/papers/15.4-wise04.pdf
802.15.4 でサポートしてるセキュリティの解説
Access control
Message integrity
Message confidentiality
Replay protection
802.15.4のProtocolの概説
この論文では 64-bit のaddressを使う時について考察している。
64-bit node identifier
16-bit network identifier
address sizeは用途によって 0 - 10 bytesに可変
セキュリティを考察する上で重要なタイプは2つ
data packet
acknowledgement packet
暗号アルゴリズムを中心にした802.15.4のSecurityの概説
data packetにしか適用されない。
8種類のセキュリティスーツ
NULL,
AES-CTR
AES-CBC-MAC-128
AES-CBC-MAC-64
AES-CBC-MAC-32
AES-CCM-128
AES-CCM-64
AES-CCM-32
4種類に大分類できる
No security
Encryption only
Integrity only
Encryption and integrity
実装必須は NULLと AES-CCM-64
255までのACLを実装(may)
802.15.4の鍵配布に関するモデルの解説
Network shared keying
Pairwise keying
Group keying
Hybrid approaches
Group keyingは Network shared keyingのサブセット。
GroupをNetwork全体に拡大すると Network shared keyingになる。
3つの問題提起
IV management
key management
integrity protection
前2つは実装依存に話しをしている。もう少し読む必要あり。
最後のは AES-CTRは integrityないから使うなと言っている。
recommendations
3つの分野に対して提案。
application designers
hardware designers
specification writers
まとめると
- integrityないからAES-CTRは使うな。
- Acknowledgement Messageは信用するな。
- (仕様は mayだが)255 ACLサポートしなさい。
- (low power modeになっても)ACLをリセットするな。
- (group keyを使う場合)nonceをアプリケーションで管理できる
仕組みを実装しなさい。
- Authenticated Acknowledgement をサポートしなさい。
"IPv6 over Low Power WPAN Security Analysis"
http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-security-analysis-00.txt
"Things to think about when Interworking 6LoWPAN and ZigBee networks"
http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-zigbee-issues-00.txt
===
ZigBee to IPv6
draft-serikaya-6lowpan-forwarding-00
Sensor nodes
run the open-source TinyOS operating system
generate TinyOS packet
be accessed from IPv6 usgin a web interface
Stargate, Serial forwarder over IPv6
a PDA with an XScale board
a serial port or USB connection
802.3 interface
Telos motes have 802.15.4 radios
TCP-based socket application
Routing protocol
is application-dependent
is mesh oriented
TinyOS packet
FCF, DSN, Dest and Group ID are ZigBee MAC Layer specific
The application has to be aware of the frame format and be capable of receiving the data and generating queries to the sensor network.