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:
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
_______________________________________________
6lowpan mailing list
[email protected]
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.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
