[6lowpan] HC

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.