1. 07/24/200769th IETF Meeting - 6LoWPAN WG1 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”

2. 07/24/200769th IETF Meeting - 6LoWPAN WG2 “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

3. 07/24/200769th IETF Meeting - 6LoWPAN WG3 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/4 th 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

4. 07/24/200769th IETF Meeting - 6LoWPAN WG4 Why Global Addresses? Monitoring and Control Applications –Collector OR controller generally not a 802.15.4 device –Conventional device on conventional link Collector/Controller 802.15.4802.3 hartcomm.org

5. 07/24/200769th IETF Meeting - 6LoWPAN WG5 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? Collector/Controller 802.15.4 Translation Gateway 802.3

6. 07/24/200769th IETF Meeting - 6LoWPAN WG6 Route directly to the data collector Possibly through different egress points Why Global Addresses? Collector/Controller 802.15.4802.3

7. 07/24/200769th IETF Meeting - 6LoWPAN WG7 Multiple PANs –May be different in PAN ID, channel, MAC, network- wide keys, etc. Why Global Addresses? 802.15.4

8. 07/24/200769th IETF Meeting - 6LoWPAN WG8 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 Why Global Addresses? 802.15.4

9. 07/24/200769th IETF Meeting - 6LoWPAN WG9 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

10. 07/24/200769th IETF Meeting - 6LoWPAN WG10 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 802.15.4 6LoWPAN Mesh/Frag LOWPAN_HC1LOWPAN_HC1g Upper Layer Protocols Global Communication Link-Local Communication

11. 07/24/200769th IETF Meeting - 6LoWPAN WG11 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 –64 bits: prefix derived from CGP, IID carried inline –16 bits: prefix derived from CGP, 6LoWPAN encoded short inline –0 bits: prefix derived from CGP, IID derived from lower layers (e.g. 802.15.4 src/dest or 6LoWPAN orig/final) Arbitrary PrefixArbitrary IID ElidedArbitrary IID ElidedSA Elided

12. 07/24/200769th IETF Meeting - 6LoWPAN WG12 HC1g Encoding Source Compression Destination Compression Version, Traffic, Flow Next Header –in-line, UCP, ICMP, TCP L4 Compression –HC2 follows SC 0 123 4 567 DCVNHL4

13. 07/24/200769th IETF Meeting - 6LoWPAN WG13 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

14. 07/24/200769th IETF Meeting - 6LoWPAN WG14 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 101ScopeGroup ID 0 123 4 567 8 901 2 345 1 FFFlagsScopeGroup ID 128 bits

15. 07/24/200769th IETF Meeting - 6LoWPAN WG15 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

16. 07/24/200769th IETF Meeting - 6LoWPAN WG16 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