Owen,
> Date: Wed, 17 Feb 2010 11:36:44 -0800
> From: Owen Kirby <[email protected]>
>
> In a route-over network, the IPv6 packet would need to be reassembled
> and decompressed at every hop to decrement TTL and check the routing
> headers.
In theory, only the IPv6 header and any routing headers need
to be uncompressed at each hop. The transport header should
not need to be uncompressed until the destination is
reached.
> In this case, the forwarding node has control over all of the
> fields and can change a compressed field into an uncompressed field (and
> vice-versa) for the next hop in the route. As I suggested, this is not
> the most efficient solution, but it works and requires the least amount
> of change from what's in the RFC.
Isn't that how RFC 4944 works today? What needs to be
changed?
It works as long as the relaying node is able to completely
uncompress the packet. Should anyone want to add a new
transport header compression later on, such as for TCP,
existing devices would not be able to relay packets that
used the new compression. This is the forward-compatibility
problem that was the subject of my original message.
The use of the uncompressed length and offsets in the
fragment headers adds a lot of implementation complexity,
but I do think that it works, as long as relaying nodes
understand all of the compressions being used.
In other words, while changing the fragmentation to make it
simpler to implement would be nice, forward compatibility is
the reason that I think we must do so.
> In the mesh-under case, the fragments get routed across the network
> using the mesh routing header in RFC4944, and reassembly only happens at
> the packet's final destination, the contents of the fragments can't be
> modified in-flight anyways, so I don't see how this would cause a
> problem, and changes in the MTU are something that the source would need
> to allow for anyways.
Mesh-under networks do not necessarily use the mesh routing
header in RFC4944. I suspect that similar problems could
come up in a mesh-under network, depending on the details of
how forwarding is accomplished.
> FWIW, all of the 6LoWPAN implementations I know of work on the
> assumption that compressed headers are always contained within the first
> fragment only.
As you pointed out earlier, that probably isn't a safe
assumption when using the HC draft. In particular, source
routes could easily push some or all of a compressed header
into the second fragment.
-Richard Kelsey
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
