On May 24, 2010, at 12:48 AM, Richard Kelsey wrote: > [Mailing list switched from roll to 6lowpan, as Carsten's > question is for that group.] > >> From: Carsten Bormann <[email protected]> >> To: [email protected] >> Date: Tue, 18 May 2010 18:33:24 +0200 >> >> On May 18, 2010, at 18:21, Pascal Thubert (pthubert) wrote: >> >>> Then 6LoWPAN can work on compressing it using 6LowpAN >>> techniques. >> >> Do we (6LoWPAN) want to? >> So far we have focused on compressing things that are very stable. >> Tracking a moving target with a compression spec is tedious. > > I agree that tracking a moving spec is problematic. > > On the other hand, we know that in the end any source route > (or record route) will be a block of IPv6 addresses with a > few fields tacked on the front. It should be possible to > work on compressing the route itself, which is where the > bulk of the compression will be in any case.
One of the reasons for including next-header-compression (NHC) in HC was to support future compression of IPv6 extension headers. Therefore if an RH0 style header would be used for source routing with full IPv6 addresses, a NHC code could be defined for compressing those addresses. Note that HC allows other documents to specify such an extension, even e.g. RPL could do that, so this doesn't necessarily need to be defined in the 6lowpan WG. Zach > > -Richard Kelsey > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
