Subject: [6lowpan] WGLC for 6lowpan HC draft

From: Geoff Mulligan <[email-masked]>
Date: Sat, 13 Feb 2010 00:56:31 -0700

Folks,
  I realized that I have made a huge slip-up.  The HC draft has languished for the past few months.
At the meeting in Hiroshima we said that we would last call this draft, but I failed to send out the
actual last call. So...

  This note formally starts the WG Last Call for comments on
draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks".

The document can be found at:
http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt

The document is intended to be submitted by this Working Group to the
IESG for publication as a Standards Track document.

Please review the document carefully (one last time), and send your
comments to the 6lowpan list.  Please also indicate in your response
whether or not you think this document is ready to go to the IESG.

Because of my gaffe this Last Call will end Wednesday February 24 2010
at 2359 UTC.

        Thanks,
                Geoff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Feb 2010 11:31:02 +0100

> whether or not you think this document is ready to go to the IESG.

I believe the document is essentially ready to go to the IESG. All I
found were a few nits:

1) p4: s/is is/is/

2) p6: s/the the/the/  (occurs twice)

3) p16: I thing the text describing port compression can be somewhat
   simplified or less confusing by avoiding the "and elided". Here is
   proposed new text:

      01:  All 16 bits for Source Port are carried in-line.  First 8
         bits of Destination Port is 0xF0 and the remaining 8
         bits of Destination Port are carried in-line.
      10:  First 8 bits of Source Port are 0xF0 and the
         remaining 8 bits of Source Port are carried in-line.  All 16
         bits for Destination Port are carried in-line.
      11:  First 12 bits of both Source Port and Destination Port are
         0xF0B and the remaining 4 bits for each are carried
         in-line.

4) I was asking myself whether more needs to be said in the security
   considerations but could not really come up with additional text.
   However, operationally, I expect it to be challenging to debug
   problems when contexts are used since knowledge about the meaning
   of the contexts is crucial to assign meaning to a conversation.
   Since the document says how information is maintained in shared
   contexts is out of scope, I guess there is not much to be done for
   this document, but hopefully some other documents will be written
   to make this less of a magic.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 19 Feb 2010 15:42:42 -0800

Hi Geoff

I have a few questions regarding Extended Header Compression:

How does one compress the "type-specific data" field in a IPv6
Routing Header? It's a variable-length field with no predefined format
given in RFC 2460. To compress this field effectively, a 6LoWPAN
encoder would need to know the formats of all the currently used
Routing Types.

Is the reserved field in the Fragment Header elided or sent
inline as 0?

If Ext Header [B] follows compressed header [A] and the options
in [B] turn out to be longer than 255 bytes during compression, how
would you adjust [A] without having to do a memmove to make space for
the inline next-header field. What I understand is that, if header [B]
itself can't be compressed, the next-header field in header [A] must be
placed in the inline portion for header A and before other inline
fields in [A]. This problem also requires one to keep a pointer back to
where the inline next-header field should be inserted. One other
solution would be to look ahead at the length of [B] before compressing
[A], but I think this can get messy.

Regard

Dario

Geoff Mulligan wrote:

Folks,

Thanks,
Geoff

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 19 Feb 2010 15:55:27 -0800

Hi Dario,

On Feb 19, 2010, at 3:42 PM, Dario Tedeschi wrote:

> 	• How does one compress the "type-specific data" field in a IPv6  
> Routing Header? It's a variable-length field with no predefined  
> format given in RFC 2460. To compress this field effectively, a  
> 6LoWPAN encoder would need to know the formats of all the currently  
> used Routing Types.

You don't compress.  If you want compact routing information, then  
create a new routing header type that utilizes compact information  
(e.g. not full IPv6 addresses).  It is likely that RPL will go this way.

> 	• Is the reserved field in the Fragment Header elided or sent  
> inline as 0?

Sent inline as is.  See this important text from hc-06:

     "For the most part, the IPv6 Extension Header is carried verbatim  
in
      the bytes immediately following the LOWPAN_NHC octet, with two
      important exceptions: Length Field and Next Header Field."

> 	• If Ext Header [B] follows compressed header [A] and the options  
> would you adjust [A] without having to do a memmove to make space  
> for the inline next-header field. What I understand is that, if  
> header [B] itself can't be compressed, the next-header field in  
> header [A] must be placed in the inline portion for header A and  
> before other inline fields in [A]. This problem also requires one to  
> keep a pointer back to where the inline next-header field should be  
> inserted. One other solution would be to look ahead at the length of  
> [B] before compressing [A], but I think this can get messy.

If you can't compress B, using NHC encoding for A doesn't buy you  
anything (actually hurts).  My approach is to first see if it makes  
sense to use NHC encoding at all by traversing the headers, then do  
the transformation if needed.

The important point here is that NHC support for IPv6 Extension  
Headers isn't really intended to compress the IPv6 Extension Headers  
themselves all that much (the only real exception is the ability to  
elide padding in options headers.  The real intended use is to allow  
NHC encoding of transport-layer headers (e.g. UDP, TCP, etc.) as we  
discussed in Stockholm.

--
Jonathan Hui

---

From: Dario Tedeschi <[email-masked]>
Date: Mon, 22 Feb 2010 11:14:25 -0800

Thanks Jonathan

A few comments below...

Jonathan Hui wrote:

• Is the reserved field in the Fragment
Header elided or sent inline as 0?

Would it not be a little clearer to the reader, if the NHC section in
hc-06 stated that reserved fields must be sent inline.

• If Ext Header [B] follows compressed
header [A] and the options in [B] turn out to be longer than 255 bytes
during compression, how would you adjust [A] without having to do a
memmove to make space for the inline next-header field. What I
understand is that, if header [B] itself can't be compressed, the
next-header field in header [A] must be placed in the inline portion
for header A and before other inline fields in [A]. This problem also
requires one to keep a pointer back to where the inline next-header
field should be inserted. One other solution would be to look ahead at
the length of [B] before compressing [A], but I think this can get
messy.

If you can't compress B, using NHC encoding for A doesn't buy you
anything (actually hurts).

What if A was an IP header? If you can't compress B using NHC, having A
compressed can still buy you a lot. So for the current NHC in the draft
there are two  implementations I see:

Before encoding the next-header field in the IP header, look
ahead at B to see if its options exceed 255 bytes.

Or, compress A then attempt to encode B, and if B's options
exceed 255 bytes, insert the next-header field in compressed A's inline
area (requires a memmove).

--

Regards

Dario Tedeschi

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 22 Feb 2010 11:29:11 -0800

Hi Dario,

On Feb 22, 2010, at 11:14 AM, Dario Tedeschi wrote:

>>     "For the most part, the IPv6 Extension Header is carried  
>> verbatim in
> Would it not be a little clearer to the reader, if the NHC section  
> in hc-06 stated that reserved fields must be sent inline.

I prefer exclusion text since the common case for IPv6 extension  
headers is to carry everything inline.  So I can certainly clarify the  
text to more explicitly indicate the common case and add in some text  
that talks directly to reserved fields that make it extra explicit  
that the common case really is to carry everything inline.

>>>     • If Ext Header [B] follows compressed header [A] and the  
>>> options in [B] turn out to be longer than 255 bytes during  
>>> compression, how would you adjust [A] without having to do a  
>>> next-header field in header [A] must be placed in the inline  
>>> portion for header A and before other inline fields in [A]. This  
>>> problem also requires one to keep a pointer back to where the  
>>> inline next-header field should be inserted. One other solution  
>>> would be to look ahead at the length of [B] before compressing  
> What if A was an IP header?

Then you wouldn't be using NHC to compress A, but IPHC instead.  My  
point is that NHC for IPv6 Extension Headers doesn't buy you much  
unless you want to elide at most 7 octets of tail padding in a Hop-by- 
Hop Options header or a transport-layer header that you'd like to also  
encode using NHC.  If a header turns out to be longer than 255 bytes,  
any savings will be relatively small compared to the size of the  
datagram.

> If you can't compress B using NHC, having A compressed can still buy  
> you a lot. So for the current NHC in the draft there are two   
> implementations I see:
> 	• Before encoding the next-header field in the IP header, look  
> 	• Or, compress A then attempt to encode B, and if B's options  
> exceed 255 bytes, insert the next-header field in compressed A's  
> inline area (requires a memmove).

Either would be logically correct and the choice should be left up to  
the implementor.

--
Jonathan Hui

---

From: Dario Tedeschi <[email-masked]>
Date: Mon, 22 Feb 2010 12:46:43 -0800

Hi Jonathan

> that the common case really is to carry everything inline.
Yes, I think that would be good.

>>>> would be to look ahead at the length of [B] before compressing [A], 
>>>> but I think this can get messy.
>>>
> unless you want to elide at most 7 octets of tail padding in a 
> Hop-by-Hop Options header or a transport-layer header that you'd like 
> to also encode using NHC.  If a header turns out to be longer than 255 
> bytes, any savings will be relatively small compared to the size of 
> the datagram.
>
I understand that; I was just wondering if there was some other way of 
handling Ext Headers without having a 255 byte limit. I'm sure it's been 
thoroughly investigated. Thanks for the clarification.

--
Dario Tedeschi

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 24 Feb 2010 13:53:30 +0100

Hi All,

I believe the document is ready to go to the IESG.
Best,
Mathilde 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Geoff Mulligan
Sent: samedi, 13. février 2010 08:57
To: 6lowpan
Subject: [6lowpan] WGLC for 6lowpan HC draft

This note formally starts the WG Last Call for comments on
draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in 6LoWPAN
Networks".

The document is intended to be submitted by this Working Group to the IESG
for publication as a Standards Track document.

Please review the document carefully (one last time), and send your comments
to the 6lowpan list.  Please also indicate in your response whether or not
you think this document is ready to go to the IESG.

---

From: Owen Kirby <[email-masked]>
Date: Wed, 24 Feb 2010 11:15:06 -0800

Geoff,

I do not support draft-ietf-6lowpan-hc-06 for IESG submission until 
there is a resolution for:
A) The forward compatibility issues raised by Richard Kelsey, and
B) The use of fragmentation when compressed headers extend beyond the 
first fragment, or an explicit statement that compressed headers must 
fit within the first fragment.

Thanks,
Owen Kirby