IPv6 Header Compression for
Global Addresses
Jonathan Hui
David Culler
draft-hui-6lowpan-hc1g-00 – “Stateless IPv6 Header Compression for
Globally Routable Packets in 6LoWPAN Subnetworks”
07/24/2007
69th IETF Meeting - 6LoWPAN WG
1
“IPv6 Communication over IEEE
802.15.4” …
• 6LoWPAN supports IP communication using
global (i.e., routable) IPv6 addresses
– But it never compresses them!
• HC1 compression only applies to the special link
local prefix.
– Shared by all nodes in the PAN
• So if you use IP over 802.15.4 for what IP is
typically used for (internetworking) you lose
much of the virtue of 6LoWPAN.
=> Complement HC1 with HC1g stateless
compression for a shared global prefix
07/24/2007
69th IETF Meeting - 6LoWPAN WG
2
Motivation
• Why global addresses?
– End-to-end communication in networks with heterogeneous links
• without a stateful (possibly application specific) translation gateway
• data collection point may be multiple IP hops away
– End-to-end communication across different PANs
– IP connects different subnetworks
• ZigBee does not
• LOWPAN_HC1 supports arbitrary addresses, but…
– Only allows compression of the link-local (fe80::/64) prefix
– Uncompressed addresses consume 32 bytes
• 1/4th the 802.15.4 MTU before link and 6LoWPAN headers!
• The Issue is compressing the origin / final IP addresses
– Not the number of PAN hops between them
07/24/2007
69th IETF Meeting - 6LoWPAN WG
3
Why Global Addresses?
• Monitoring and Control Applications
– Collector OR controller generally not a 802.15.4 device
– Conventional device on conventional link
802.15.4
802.3
Collector/Controller
07/24/2007
hartcomm.org
69th IETF Meeting - 6LoWPAN WG
4
Why Global Addresses?
• Monitoring and Control Applications
– Collector/controller often connected using other links
• Link-local requires a stateful translation gateway
• What about multiple 802.15.4 egress points?
– Good for redundancy
– But requires a translation gateway at each
– How is state managed across them?
802.3
802.15.4
Translation Gateway
07/24/2007
69th IETF Meeting - 6LoWPAN WG
Collector/Controller
5
Why Global Addresses?
• Route directly to the data collector
• Possibly through different egress points
802.15.4
802.3
Collector/Controller
07/24/2007
69th IETF Meeting - 6LoWPAN WG
6
Why Global Addresses?
• Multiple PANs
– May be different in PAN ID, channel, MAC, networkwide keys, etc.
802.15.4
07/24/2007
802.15.4
69th IETF Meeting - 6LoWPAN WG
802.15.4
7
Why Global Addresses?
802.15.4
• Assigned IP addresses within a PAN
– IP addresses are useful for naming
– If assigned IP address is used to name source or
destination, no HC1 compression
• Assigned prefix or assigned interface identifier
07/24/2007
69th IETF Meeting - 6LoWPAN WG
8
HC1g - In a Nutshell
• Shared context of the PAN includes its prefix
• Define compression for prefix other than link-local
– PAN has a compressible global prefix (CGP)
• Compression of Interface IDs derived from short addrs
• Similar to LOWPAN_HC1 encoding
–
–
–
–
Compresses to 2 octets in best case
Allows arbitrary IPv6 addresses if needed
Same encoding octet
Uses lower-layer information when possible
• Support for compressed well-known multicast addresses
– Neighbor discovery, DHCPv6
– Uses 6LoWPAN short address encoding
07/24/2007
69th IETF Meeting - 6LoWPAN WG
9
HC1g Compliments HC1
• HC1 and HC1g identified by different dispatch values
• HC1 is efficient for link-local communication
• HC1g is efficient for off-link communication
– Or on-link using non-default prefix
Upper Layer Protocols
Link-Local Communication
LOWPAN_HC1
Global Communication
LOWPAN_HC1g
6LoWPAN Mesh/Frag
802.15.4
07/24/2007
69th IETF Meeting - 6LoWPAN WG
10
LOWPAN_HC1g Addresses
• PAN has a compressible global prefix (CGP) associated with it
– Prefix is elided whenever it matches the CGP
• Four HC1g address forms:
– Full 128 bits for arbitrary IPv6 addresses
Arbitrary Prefix
Arbitrary IID
– 64 bits: prefix derived from CGP, IID carried inline
Elided
Arbitrary IID
– 16 bits: prefix derived from CGP, 6LoWPAN encoded short inline
Elided
SA
– 0 bits: prefix derived from CGP, IID derived from lower layers (e.g.
802.15.4 src/dest or 6LoWPAN orig/final)
Elided
07/24/2007
69th IETF Meeting - 6LoWPAN WG
11
HC1g Encoding
•
•
•
•
Source Compression
Destination Compression
Version, Traffic, Flow
Next Header
– in-line, UCP, ICMP, TCP
0
1
2
3
4
5
6
7
SC DC V NH L4
07/24/2007
• L4 Compression
– HC2 follows
69th IETF Meeting - 6LoWPAN WG
12
LoWPAN HC1g 16-bit Addr
• 16-bit short address follows 6LoWPAN encoding
• Compression of IIDs derived from 802.15.4 short address
– 802.15.4 short address when first bit is 0
– Upper 48-bits of IID is assumed to be zero
– U/L bit is also zero, indicating local scope
• Well-known multicast addresses
– 16 bits starts with ’101’
– Allocates another range in 6LoWPAN short address encoding
• Neither are supported in LOWPAN_HC1
07/24/2007
69th IETF Meeting - 6LoWPAN WG
13
Multicast Address Compression
• For commonly-used, well-known multicast addresses
• Use 6LoWPAN short address encoding
– Prefix (8-bits): Compressed to 3-bit range
– Flags (4-bits): Assumed to be zero
• permanent, not derived from prefix, doesn’t embed RP
– Scope (4-bits): Carried in-line
– Group ID (112-bits): Mapped to 9-bits
• Only all-nodes and all-routers currently defined
• Can be used in LOWPAN_HC1g or Mesh Addressing
128 bits
FF Flags
Scope
0
1
Group ID
2
1 0 1
07/24/2007
3
4
5
Scope
6
7
8
9
1
0
1
2
3
4
5
Group ID
69th IETF Meeting - 6LoWPAN WG
14
Other Differences
• Changes made based on lessons learned from LOWPAN_HC1
implementations
• Possible lack of octet alignment
–
–
–
–
Can consume several hundred bytes of code
Octet alignment broken in uncommon cases
Saves at most one octet in best case (when used with HC_UDP)
HC1g include 4-bit version field with Traffic Class and Flow Label
• HC_UDP not possible when using IP extension headers
– HC2 bit changed to specify layer 4 compression
• Only UDP is currently valid, ICMP/TCP not yet defined
07/24/2007
69th IETF Meeting - 6LoWPAN WG
15
HC1g summary
• Compression for prefixes other than link-local
– PAN has a compressible global prefix (CGP)
• Compression of Interface IDs derived from short addrs
• Similar to LOWPAN_HC1 encoding, but for CGP
–
–
–
–
Compresses to 2 octets in best case
Allows arbitrary IPv6 addresses if needed
Same encoding octet, same HC2
Uses lower-layer information when possible
• Support for compressed well-known multicast addresses
– Neighbor discovery, DHCPv6
– Uses 6LoWPAN short address encoding
07/24/2007
69th IETF Meeting - 6LoWPAN WG
16