It appears that the 6LoWPAN WG is poised to take up serious discussion of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) and I would like to encourage us to make a bold move forward while the number of "dusty deck 6LoWPAN implementations" are few - eliminate HC1/HC2 in the process.
As a bit of background, the original format document defined HC1 for compression of link local IPv6 addresses and HC2 for compression of UDP and ICMP headers. Both were part of a rather awkward encoding. Most other parts of the encoding got cleaned up with the switch to the stacked header format that went to RFC. Aside from its awkwardness, HC1 was never sufficient, because it provided no compression of routable addresses, nor for the most useful multicast addresses - both rather essential to IPv6. HC1g was proposed to provide a similar (somewhat more effective) stateless compression of common addresses of global scope. This meant two similar compression schemes, HC1 for link-local, HC1G for global. Both are implementable with much less than a thousand lines of code. No ambiguity about when to use which. HC provides a much cleaner approach which subsumes both HC1 and HC1g, better supports multicast, and is much more usable with IPv6 stacked headers because the order of the subheaders is respected. (HC2 comes in between the dispatch and the address subheader, rather than as a portion of the transport subheader). The decision to take on HC, clean up the rough edges, and build consensus around it is the easy part. The bolder step that I would like to suggest is that we deprecate HC1 and get it removed soon. It is always easier to maintain backward compatibility than to make a clean break. But, ultimately that is burdening all the many future implementations in order to avoid a burden on the few current implementations. The reason to avoid this burden is not that either is a huge amount of code. Implementing any of these HCs is only several hundred LOC. The issue is testing and interoperability. The interoperability draft sheds some light on this. There are so many different compression forms and since each is an optimization on the uncompressed version, there are many different ways to represent the same thing. All with different sizes and offsets. At least they are all in the same suite. To multiply that with all the combinations of HC1 and HC will be really unpleasant. Moreover, the only thing anyone will ever use after a short while is HC, since it is so much cleaner and more effective. That means all the HC1 mess and all the testing and interoperability investment will be for nothing other than that - just to pass the test. But it will generate latent bugs, increase the footprint, and frustrate interoperabilty. So, as we imagine a future of billions of 6LoWPAN IP devices embedded in important hard to reach places, lets take the step now to simplify their implementation and testing, rather worry too much about saving a few hours of coding for the half dozen existing implementations. If that is not reason enough, those same implementors will save many times that amount in reduced testing and interoperability validation.
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
