I'd like to make a bold proposal. If we now decide to take HC into use,
and depreciate HC1 (momentum seems to be there); I would like to go one
step further. Let's depreciate the use of the RFC 4944 mesh-header at
the same time.
draft-hui-6lowpan-hc-00 now allows us to do everything which the
mesh-header does, and more. Sending packets to a global IPv6 node using
the mesh header now requires both the mesh-header, plus an L3
destination address. Quite inefficient. Plus there is again the issue of
implementation, testing, and interop along with a confusing spec where
routing src/dst can be carried both in lowpan and IPv6 headers.. This
situation is similar to that of HC1 and HC. The mesh-header will slowly
depreciate anyways, especially with ROLL activity, and for interop
reasons between vendors. Let's depreciate it now and stop the annoying
mesh-under vs. route-over confusion.
LOWPAN_BC0 would still be used to eliminate duplicates.
At Sensinode we are likely the largest production deployers with the
mesh-header at this time, and are willing to move to L3 at the same time
as HC. How about other implementors using the mesh-header, can you
support this motion? Can anyone think of a reason to keep the mesh header?
- Zach
--
Zach Shelby | Head of Research | +358 40 7796297
Sensinode Ltd. www.sensinode.com
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
