Subject: [6lo] To HC or not to HC? That is the question.

From: Kerry Lynn <[email-masked]>
Date: Thu, 23 Apr 2015 13:53:31 -0400

Following the presentation of
https://tools.ietf.org/html/draft-ietf-6lo-6lobac-01 at IETF92,
I believe the only comment made was that it should disallow uncompressed
IPv6 headers
(LOWPAN dispatch pattern 01 000001).

In response, I think the draft should make it clearer that 6LoBAC hosts
MUST support
LOWPAN_IPHC compressed headers, but MAY support uncompressed IPv6 headers as
well.

I find this a relatively low-cost option to support, even though others
have pointed out that
coding for full IPv6 headers is error-prone.  My rationale is that some
vendors may prefer
the overhead cost of full headers over that of 6CO context distribution.
This is especially
true if 64-bit privacy IIDs are in use.

I'd like to ask the chairs to initiate WGLC on this draft so we can reach a
timely consensus
on this issue as well as any others.

Regards, Kerry Lynn

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Apr 2015 21:05:20 +0200

On 23 Apr 2015 at 19:54:06, Kerry Lynn ([email-masked]) wrote:
Following the presentation of https://tools.ietf.org/html/draft-ietf-6lo-6lobac-01 at IETF92,
I believe the only comment made was that it should disallow uncompressed IPv6 headers
(LOWPAN dispatch pattern 01 000001).
I think you are referring to my comment.

In response, I think the draft should make it clearer that 6LoBAC hosts MUST support
LOWPAN_IPHC compressed headers, but MAY support uncompressed IPv6 headers as
well.
That MAY is a burden on every receiver.  Since people may want to test this in interop tests, it easily becomes a burden on senders as well.

I find this a relatively low-cost option to support, even though others have pointed out that
coding for full IPv6 headers is error-prone.  My rationale is that some vendors may prefer
the overhead cost of full headers over that of 6CO context distribution.  This is especially
true if 64-bit privacy IIDs are in use.
That is a false choice.  

You can run RFC 6282 fine without any 6CO context distribution.  You get fewer benefits, but the difference can still be sizable, more so when short MAC addresses are in use.

So I still believe there should be no “IPv6 uncompressed” equivalent in any new 6Lo spec.

I agree that we can sort this one detail out during WGLC, so let’s go ahead with that.

Grüße, Carsten

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 23 Apr 2015 16:20:38 -0400

> I think you are referring to my comment.
Indeed, which is why I'm concerned I may be missing something.

> That MAY is a burden on every receiver.  Since people may want to test
> this in interop tests, it easily becomes a burden on senders as well.
>
I'm not saying the option has zero cost, just that the cost may be
preferable to complexity
elsewhere in the system in certain deployments.

Are you referring to a burden in terms of code size?  I'd be shocked if it
was more than 100
bytes, but I'll try to characterize this for Contiki on an AVR in the next
days.

> You can run RFC 6282 fine without any 6CO context distribution.  You get
> fewer benefits, but the difference can still be sizable, more so when short
> MAC addresses are in use.
>
I don't dispute this, which is why support for IPHC is a MUST.  (As an
aside, I wonder if it's
appropriate for a 6Lo draft to specify that SCI==0 and DCI==0 *always*
refer to FE80::/64,
even if 6CO distribution is in use?)

Where I think the cost of maintaining compressed headers outweighs the
benefits, on this
data link type, is if/when 64-bit privacy IIDs are in use.  Of the three
options presented in
https://tools.ietf.org/id/draft-thaler-6lo-privacy-addrs:
- Option 1 is not indicated, since MS/TP does not use IEEE addressing
- Option 2 is not indicated, since there is no per-network key that can be
used as input to the hash
That leaves option 3, which if I recall got little support from the WG and
seems like it would
require work to other RFCs in order to implement.  IMO, a better option is
to send the header
uncompressed.

Regards, Kerry

---

From: Robert Cragie <[email-masked]>
Date: Fri, 24 Apr 2015 15:23:27 +0100

Not sure if this got through earlier...

Robert

-------- Forwarded Message --------
Subject: 	Re: [6lo] To HC or not to HC? That is the question.
Date: 	Fri, 24 Apr 2015 11:13:51 +0100
From: 	Robert Cragie <[email-masked]>
Reply-To: 	[email-masked]
Organization: 	Gridmerge Ltd.
To: 	Kerry Lynn <[email-masked]>, Carsten Bormann <[email-masked]>
CC: 	[email-masked] <[email-masked]>

Hi Kerry,

Comments inline. In brief - I don't think IPv6 dispatch code needs to be 
supported.

Robert

On 23/04/2015 21:20, Kerry Lynn wrote:
> On Thu, Apr 23, 2015 at 3:05 PM, Carsten Bormann <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 23 Apr 2015 at 19:54:06, Kerry Lynn ([email-masked]
>     <mailto:[email-masked]>) wrote:
>>     Following the presentation
>>     ofhttps://tools.ietf.org/html/draft-ietf-6lo-6lobac-01at IETF92,
>     That MAY is a burden on every receiver.  Since people may want to
>     test this in interop tests, it easily becomes a burden on senders
>     as well.
>
<RCC>I tend to agree with Carsten here. There is no benefit in using the 
IPv6 dispatch code. You can carry full IPv6 addresses inline with IPHC 
as well (SAC/DAC == 0, SAM/DAM == 0b00) so the IPv6 dispatch code is 
redundant really.</RCC>
>
> Are you referring to a burden in terms of code size? I'd be shocked if 
> it was more than 100
> bytes, but I'll try to characterize this for Contiki on an AVR in the 
> next days.
>
>     You can run RFC 6282 fine without any 6CO context distribution. 
>     You get fewer benefits, but the difference can still be sizable,
>     more so when short MAC addresses are in use.
>
<RCC>
In ZigBee IP we have:

* SAC/DAC == 0, CID == x, SAM/DAM != 0b00  to represent a link local prefix
* SAC/DAC == 1, CID == 0, SAM/DAM != 0b00  to represent the 6LBR prefix 
associated with PIO and 6CO in the RA
* SAC/DAC == 1, CID == 1, SCI/DCI == [0..15], SAM/DAM != 0b00  to 
represent other contexts

So I am not sure why you would be using SCI/DCI == 0 for link local prefix
</RCC>

> data link type, is if/when 64-bit privacy IIDs are in use.  Of the 
> three options presented in
> - Option 2 is not indicated, since there is no per-network key that 
> can be used as input to the hash
> That leaves option 3, which if I recall got little support from the WG 
> and seems like it would
> require work to other RFCs in order to implement. IMO, a better option 
> is to send the header
> uncompressed.
<RCC>...which you can still do with IPHC and I would imagine in many 
cases you can still elide the prefix, saving you 8/16 bytes</RCC>
>     equivalent in any new 6Lo spec.
<RCC>If IPHC is being used (and this is pretty much de facto now), I 
agree it should be deprecated</RCC>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Robert Cragie <[email-masked]>
Date: Fri, 24 Apr 2015 11:13:51 +0100

Hi Kerry,

Robert

<RCC>
In ZigBee IP we have:

> require work to other RFCs in order to implement.  IMO, a better 
> option is to send the header
> uncompressed.