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
