Division By Zero

ゼロで割る

6LowPANについて少し考えてみた - その2

前回の続き。

6LowPANのヘッダ圧縮についてはRFC4944(2007年9月)にて標準化され、その後、RFC6282(2011年9月)にて更新されている。

LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of
IPv6 in 6LoWPANs.

http://www.ietf.org/rfc/rfc6282.txt

とあるように、RFC4944で標準化されたHC1(IPヘッダの圧縮)とHC2(UDPヘッダの圧縮)だけでは現実の問題を解決できない、と判断されたようだ。

LOWPAN_HC1 is most effective for link-local
unicast communication, where IPv6 addresses carry the link-local
prefix and an Interface Identifier (IID) directly derived from IEEE
802.15.4 addresses. In this case, both addresses may be completely
elided. However, though link-local addresses are commonly used for
local protocol interactions such as IPv6 Neighbor Discovery
[RFC4861], DHCPv6 [RFC3315], or routing protocols, they are usually
not used for application-layer data traffic, so the actual value of
this compression mechanism is limited.

http://www.ietf.org/rfc/rfc6282.txt

HC1はIPv6近隣探索(ND)やDHCPv6、その他ルーティングプロトコルで使われる、IPv6リンクローカルユニキャストでは効果的だが、(IPv6リンクローカルユニキャストでない)アプリケーションレイヤのデータでの効果は限定されてしまうとのこと。これはどういうことか。

HC1ではIPv6ヘッダ40オクテットを下記のように最小で3オクテットに圧縮する。

IPv6 LOWPAN_HC1
HC1 Dispatch 0 bit 8 bit
Version 4 bit 0 bit
Traffic Class/Flow Label 28 bit 1 bit
Payload Length 16 bit 0 bit
Next Header 8 bit 2 bit
Hop Limit 8 bit 8 bit
Source/Destination 256 bit 4 bit
HC2 encoding 0 bit 1 bit
total 320 bit 24 bit

考え方を整理すると、こんなところか。

  1. 不要なものは削除(Version)
  2. 必要なものはそのまま(Hop Limit)
  3. L2等の情報と重複するものは省略(Payload Length, Source, Destination)
  4. 省略できない場合のためにフラグを残し、必要な場合のみインラインに載せる(Source, Destination, TC/FL, HC2)

SourceとDestinationでは、それぞれ2 bitを使い、前半64 bitをインラインに載せる/載せない、後半64 bitをインラインに載せる/載せないを表現。リンク内の通信であれば、SourceとDesitinationの両方で、前半/後半共に「載せない」ことができるため、ヘッダ長は短くなる。それが、リンク外との通信になると、SourceかDesitinationどちらかの128 bitと、一方の前半64 bitをインラインに「載せる」必要があり、残った後半64 bitもshort addressを使っている802.15.4リンクでは「載せる」必要が出てくる。また、マルチキャストアドレスを圧縮する仕組みがなく、128 bit全て「載せる」必要がある。

これをRFC6282ではどう解決するのか。長くなったので今日はこれで終了!

続きはこちら