Hi Gab,
The updated section still mentions the possibility that the source
address is not changed by the forwarder,
" Notice that whereas the destination link-layer address
changes at every hop, no such change applies to the source
link-layer address. The latter always points at the initial
originator of the frame being forwarded."
I doubt that this is even possible for devices that implement
LowPAN as a software layer sitting atop existing 802.15.4
radios like the CC2420, unless, before sending each packet,
the device changes its MAC address. Besides the other
issues you point out in the draft, having an intermediate
node emit an 802.15.4 header with someone else's
source address also breaks 802.1.5.4 layer security.
Consider node A sending packets for node C via node
B. A and B have a security association (algorithm, key etc)
as do B and C. What security processing should B apply
on the packet before it sends it to C if it also wishes to
keep A as the src address? [If one assumes that A, B and
C all use a common key, then there are problems with
replay protection as mentioned in the Sastry/Wagner paper]
So it seems to me that including the source explicitly
(like the destination) is the best option. And that one
should use short addresses to minimize the addressing
overhead.
vipul
Begin forwarded message:
Please read the updated section 9 on mesh delivery and comment. That
section
is available here:
http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-
format-00a.htm#mesh
http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-
format-00a.txt
I include it below for your convenience.
-gabriel
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
