Subject: [6lowpan] HC - IPv6 Extension Headers

From: Jonathan Hui <[email-masked]>
Date: Tue, 7 Apr 2009 12:06:28 -0700

Hi Everyone,

During the WG meeting, we discussed the need to add support for IPv6  
extension headers. There are two points to supporting IPv6 extension  
headers:
1) Allowing upper-layer header compression (e.g. UDP) in the presence  
of IPv6 extension headers.
2) Allowing more compact forms of IPv6 extension headers.

 From the WG meeting, there seemed to be consensus that case 1 is  
important to support. In particular, there are good use cases for IPv6  
extension headers in 6lowpan networks. The proposal to support case 1  
that was discussed in the meeting is as follows:

The LOWPAN_NHC encoding for an IPv6 extension header involves a 7-bit  
NHC identifier followed by a 1-bit NH  field that indicates whether  
the Next Header field is carried inline or the following header is  
compressed using LOWPAN_NHC. The encoding follows the following format:

   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 0 | 0 | Type  |NH |
+---+---+---+---+---+---+---+---+

Type:
  - 0: Hop-by-Hop Options Header
  - 1: Routing Header
  - 2: Fragment Header
  - 3: Destination Options Header

NH: Next Header
  - 0: Full 8 bits for Next Header are carried in-line.
  - 1: The Next Header field is compressed and the next header is  
compressed using LOWPAN_NHC

When LOWPAN_NHC is used for all IPv6 extension headers and the upper- 
layer header, the end result is that the 8-bit Next Header field is  
replaced by 8-bit LOWPAN_NHC encoding above. No other changes to the  
IPv6 extension headers are required.

The above is probably a good base level of support for IPv6 extension  
headers. But now to address the second point: allowing more compact  
forms of IPv6 extension headers. The main concern here is on the 8- 
octet granularity of the Hdr Ext Len field in the Hop-by-Hop and  
Destination Options headers, wasting up to 7 bytes of padding. There  
are two ways we can overcome this:
1) Change the meaning of the Hdr Ext Len field to 1-octet granularity  
when LOWPAN_NHC is in use. If Hdr Ext Len truly exceeds 255, then  
LOWPAN_NHC cannot be used - a rare case, I think, but still needs to  
be addressed.
2) Remove the Hdr Ext Len field all together, save another byte, and  
rely on the length field of each option to reach the next header. The  
downside is that one cannot simply jump to the next header without  
going through each option. In practice, I don't see 6LoWPAN networks  
including a large number of options.

In both cases, Pad1 and PadN options cannot be elided unless they  
appear at the end of the options list. This is to make sure that any  
alignment requirements for the options are satisfied when expanding  
the datagram.

Note that changing the meaning of the Length field (Case 1) can also  
be applied to the Routing Header. Finally, I don't think there is much  
we can do with the Fragment Header.

So some questions to guide the discussion:
- What do people think of the basic support for IPv6 extension headers?
- What do people think about changing the length field to 1-octet  
granularity?
- What do people think about removing the length field from the hop-by- 
hop/destination options headers?

We are down to two open issues before we can LC the HC document (the  
other being compression of multicast addresses). I'd like to resolve  
these issues hopefully within the next week so that we can move  
quickly towards LC. So send your thoughts!

Thanks.

--
Jonathan Hui

---

From: Zach Shelby <[email-masked]>
Date: Tue, 07 Apr 2009 23:38:48 +0300

Hi,

Regarding the base support, I strongly think we need this as it is 
broken as is if you try to use header options with UDP NHC.

Regarding option 1 (1-octet granularity), I would find this very useful 
for piggybacking small hop-by-hop options and in general options 
followed by a payload as frames are extremely limited already.

Regarding option 2 (eliding Hdr Ext Len), this is nice and helps 
compress options even more. Agreed that there are typically very few 
options. I support this as well.

- Zach

Jonathan Hui wrote:
> 1) Allowing upper-layer header compression (e.g. UDP) in the presence of 
> IPv6 extension headers.
> NHC identifier followed by a 1-bit NH  field that indicates whether the 
> Next Header field is carried inline or the following header is 
> When LOWPAN_NHC is used for all IPv6 extension headers and the 
> upper-layer header, the end result is that the 8-bit Next Header field 
> is replaced by 8-bit LOWPAN_NHC encoding above. No other changes to the 
> forms of IPv6 extension headers. The main concern here is on the 8-octet 
> granularity of the Hdr Ext Len field in the Hop-by-Hop and Destination 
> Options headers, wasting up to 7 bytes of padding. There are two ways we 
> can overcome this:
> LOWPAN_NHC cannot be used - a rare case, I think, but still needs to be 
> addressed.
> downside is that one cannot simply jump to the next header without going 
> through each option. In practice, I don't see 6LoWPAN networks including 
> a large number of options.
> 
> In both cases, Pad1 and PadN options cannot be elided unless they appear 
> at the end of the options list. This is to make sure that any alignment 
> requirements for the options are satisfied when expanding the datagram.
> 
> Note that changing the meaning of the Length field (Case 1) can also be 
> applied to the Routing Header. Finally, I don't think there is much we 
> can do with the Fragment Header.
> 
> - What do people think about removing the length field from the 
> hop-by-hop/destination options headers?
> 
> these issues hopefully within the next week so that we can move quickly 
> towards LC. So send your thoughts!
> 
> Thanks.
> 
> -- 
> Jonathan Hui
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

-- 
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Apr 2009 15:08:18 +0200

Hi Jonathan:

So a compressed packet will have a number of (LOWPAN_NHC + rest of
option) in sequence.

>- What do people think of the basic support for IPv6 extension headers?
I love it. I think that ROLL might need compressing routing headers and
we could very well be deprecating mesh header altogether.

>- What do people think about changing the length field to 1-octet
Rather positive since it save stuff -trailer pads - and is easy to do,
not sure it's important

>hop/destination options headers? 
Rather negative for complexity reason, not sure it's important either.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Hui
>Sent: mardi 7 avril 2009 21:06
>To: [email-masked]
>Subject: [6lowpan] HC - IPv6 Extension Headers 
>
>
>Hi Everyone,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2009 16:13:54 +0200

Jonathan, I have some remarks to the questions you raise below.  I may 
not have the full context, but I'm trying to get up to speed with 6lowpan.

> compressed using LOWPAN_NHC. The encoding follows the following format:

AH, ESP and MH no?

[...]
> In practice, I don't see 6LoWPAN networks including a large number of
> options.

But is or isn't the 6LoWPAN network connected to the Internet: if yes 
then one particular node having a 6lowpan interface could connect to the 
Internet through the 6lowpan network, and use its existing IPv6 stack 
the way it uses it when connecting to Ethernet, for example.  In this 
case, there are many options needed (Mobile IP, AH/ESP to name a few).

[...]
> - What do people think of the basic support for IPv6 extension headers?

A side comment to this question: I would have preferred that the most 
basic IPv6 support in 6lowpan works without header compression, and 
compression to come as an optimization.  And in the context of this 
question as a full-fledged optimization covering all the currently 
specified extensions headers.

This is just a side remark.

> hop-by-hop/destination options headers?

Removing the header extension length field from the hbh/do1/2 extension 
headers would be too hard to achieve, no?  All the software using these 
extensions headers will have to be modified?

There are a number of WGs where these extensions have been used 
(together with the length field) and one would make sure interact with 
these WGs before deciding removing the respective field.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Apr 2009 17:06:17 +0200

>> NHC identifier followed by a 1-bit NH  field that indicates whether
the
>>  - 3: Destination Options Header

Bit 4 does not have to be forced to 0 so we could actually support these
by making the type 3 bits.
Jonathan, what do you think?

Pascal

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 8 Apr 2009 09:57:48 -0700

> Jonathan, what do you think?

Sounds good to me. So maybe we should expand to the following:

0: Hop-by-Hop Options
1: Routing
2: Fragment
3: Destination Options
4: Encap Security Payload
5: Authentication Header
6: Mobility Header
7: Reserved

What about changing the meaning of the Length field in the  
Authentication and Mobility headers? Authentication header is a bit  
different since it specifies 4-octet units.

Do we have a good header for type 7? :-)

What do others think?

--
Jonathan Hui

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 8 Apr 2009 13:45:32 -0400

From: Jonathan Hui <[email-masked]>
   Date: Wed, 8 Apr 2009 09:57:48 -0700

   0: Hop-by-Hop Options
   1: Routing
   2: Fragment
   3: Destination Options

I have lost the thread a bit here.  How many bytes do we
save by having an NHC identifier for a particular extension
header type?  It seems likely that the marginal advantage
of adding each new NHC identifier is decreasing.  Why pick
these seven in particular?
                                   -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Apr 2009 19:56:30 +0200

> I have lost the thread a bit here.

I actually was lost a couple of messages earlier, already.

Can someone give a worked example of how, e.g., the ESP case would  
look like?
(All headers in the uncompressed and compressed case, not just the NHC  
byte.)

It may be worthwhile to look into RFC 5225, which represents the  
latest thinking we had in ROHC about extension headers (of course, for  
a different use case).

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 8 Apr 2009 10:57:32 -0700

Hi Richard,

Defining NHCs for each extension header allows the use of LOWPAN_NHC  
when those extension headers are present, saving up to 6 bytes. Note  
that the current proposal for supporting extension headers only  
replaces the Next Header field with the NHC encoding - so no  
additional bytes are added in the worst case.

If we change the meaning of the Length field from 8-octet units to 1- 
octet units, then we save up to 7 bytes per extension header.

The 7 extension headers listed are the only IPv6 extension headers  
that I am aware of, though, in my last email, I did solicit the WG for  
other headers lurking out there in case I missed them.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 8 Apr 2009 11:36:49 -0700

Hi Carsten,

The basic idea is to provide a simple mechanism that allows 6lowpan to  
support chaining across IPv6 extension headers and not compression of  
those headers themselves. So simply replace the Next Header/Protocol  
ID field with what is effectively a 7-bit header identifier + 1-bit  
field to indicate whether or not the Next Header/Protocol ID field is  
elided.

As a minor improvement, we are also considering changing the  
resolution of the Ext Hdr Len field in headers that contain one, most  
notably the options and routing headers, to remove unnecessary padding  
at the tail of a header.

That's really it. You're right that the ESP header is a bit of an odd  
ball since the Next Header field appears at the end of the extension  
header, but I don't see a show stopper in supporting that.

The examples you requested are below. Do you see any issues with the  
transformations? With the ESP header in particular?

Hop-by-Hop/Destination Options:

Original:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |    Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LOWPAN_NHC:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0 0 0 1|  Hdr Ext Len  |    Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Routing

Original:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LOWPAN_NHC:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0 0 1 1|  Hdr Ext Len  |  Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fragment

Original:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   Reserved    |     Fragment Offset     |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LOWPAN_NHC:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0 1 0 1|   Reserved    |     Fragment Offset     |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Authentication Header

Original:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Payload Len  |           RESERVED            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LOWPAN_NHC:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 1 1|  Payload Len  |           RESERVED            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Mobility Header

Original:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto |  Header Len   |   MH Type     |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LOWPAN_NHC:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 1 0 1|  Header Len   |   MH Type     |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Encapsulating Security Payload

Original:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Security Parameters Index (SPI)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Payload Data* (variable)                   |
~                                                               ~
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |     Padding (0-255 bytes)                     |
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |  Pad Length   | Next Header   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LOWPAN_NHC:

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 1 0 0 1|        Security Parameters Index (SPI)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  SPI cont.    |               Sequence Number                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq cont.    |          Payload Data* (variable)             |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
~                                                               ~
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |     Padding (0-255 bytes)                     |
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |  Pad Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
Jonathan Hui

On Apr 8, 2009, at 10:56 AM, Carsten Bormann wrote:

> (All headers in the uncompressed and compressed case, not just the  
> NHC byte.)
>
> latest thinking we had in ROHC about extension headers (of course,  
> for a different use case).
>
> Gruesse, Carsten
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2009 22:28:59 +0200

> 4: Encap Security Payload

It covers extension headers defined in rfc2460 "IPv6 spec" and rfc3775 
"Mobile IPv6".  They're intertwinned at
http://www.iana.org/assignments/protocol-numbers/

Method should consider that DO may appear twice, but same type. (DO1 and 
DO2, and no more).  Also, if there's a jumbogram hop-by-hop extension 
header the total length of the packet comes from that hbh option (and 
not from the base header).

In addition, there's ongoing work about a new generic extension header, 
GIEH: draft-krishnan-ipv6-exthdr-06 which may or may not fly.  If it 
flies, IANA is going to assign a new type for it.

And there may also be this CGA extension header 
draft-dong-savi-cga-header-00.txt.  Or HIP extension headers 
draft-nikander-hip-hiccups-01.

> Authentication and Mobility headers?

I am not sure what you mean by changing the meaning?  Do you mean to 
change the way 6lowpan Header Compression interprets these Length 
fields?  Or the way e.g. rfc2460 "IPv6" should be modified?

> Authentication header is a bit 

I guess type 7 being there is a potentially good way to say we don't 
know now all the extension headers (but maybe later we will).

It should probably be longer than 1bit.

> What do others think?

I am also interested in other opinions.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Apr 2009 22:30:53 +0200

Jonathan Hui a écrit :
> when those extension headers are present, saving up to 6 bytes.

It could save more if more extension headers are present.  For example 
often both ESP and AH are present.

Alex

  Note
> that the current proposal for supporting extension headers only replaces 
> the Next Header field with the NHC encoding - so no additional bytes are 
> added in the worst case.
> 
> If we change the meaning of the Length field from 8-octet units to 
> 1-octet units, then we save up to 7 bytes per extension header.
> 
> The 7 extension headers listed are the only IPv6 extension headers that 
> I am aware of, though, in my last email, I did solicit the WG for other 
> headers lurking out there in case I missed them.
> 
> -- 
> Jonathan Hui
>