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.
Jonathan Hui a écrit :
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
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).
[...]
So some questions to guide the discussion:
- 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.
- 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?
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
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
