Subject: [6lowpan] Re: MultiHop Format document issues

From: Vipul Gupta <[email-masked]>
Date: Fri, 14 Oct 2005 16:58:09 -0700

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-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 18 Oct 2005 03:23:06 -0700 (PDT)

Hi Vipul,

--- Vipul Gupta <[email-masked]> wrote:
...
> should use short addresses to minimize the addressing

I am convinced of this as well. In the note I added, I say so, although it
was not clear.

I think for the upcoming rev we should add that original source field, yes.
Any objections?

-gabriel

---

From: Vipul Gupta <[email-masked]>
Date: Tue, 18 Oct 2005 10:55:09 -0700

Hi Gab,

The proposal to include the original source (in addition to the final  
destination)
sounds good to me.

A related issue on which I'd like to see some more discussion is
the inclusion of the original link src and final link dst on a per IP  
datagram
v/s per fragment basis.

If we use short addresses (2 bytes), then including this information
in each fragment introduces around 4 bytes
of overhead but allows the fragments to move through the
multihop network quickly. Otherwise, the full packet would need
to be reassembled at each hop which seems quite burdensome
and unnecessarily restrictive.

The way I understand the current draft at:
http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan- 
format-00a.htm
the final destination info (which is needed to look
up the next hop at each intermediate point in the path) is only
carried in the first fragment. Is this correct or just a  
misunderstanding
on my part?

vipul

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 18 Oct 2005 11:41:34 -0700 (PDT)

> carried in the first fragment. Is this correct or just a  

The latter. If you look at the packet formats:

http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.htm#anchor6

You'll notice that the 'M' bit (and the use of the final destination field) are persent
in all
three variations, so yes, even middle and final fragments have this capability of being
delivered in a mesh.

-gabriel

---

From: Vipul Gupta <[email-masked]>
Date: Tue, 18 Oct 2005 13:17:15 -0700

> The latter. If you look at the packet formats:

That's good to know.

Perhaps the draft could be made clearer in this respect. In particular,
I misunderstood this part in Section 9.2

"This implies that the "Final Destination" field will immediately 
follow an unfragmented packet as per Figure 1 (i.e., preceding the IPv6 
Header), or immediately following the first fragment header as per 
Figure 2."

as precluding the inclusion of the "Final Destination" in fragments
other than the first.

vipul

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 18 Oct 2005 17:06:01 -0700 (PDT)

> as precluding the inclusion of the "Final Destination" in fragments

Ah, yes, confusing. I've changed that paragraph to this, which hopefully works better:

   Mesh delivery is enabled by setting the 'M' bit present in all
   variations of the LoWPAN encapsulation (Section 4).  If the 'M' bit
   is set, there is a "Mesh Delivery" field included in the frame
   immediately following the LoWPAN header.  More precisely, in all
   variations of the LoWPAN encapsulation (unfragmented and fragmented),
   the "Mesh Delivery" field immediately precedes the LoWPAN payload
   (e.g., a full-blown IPv6 header, a compressed IPv6 header as per
   Section 8, or any others defined elsewhere).

-gabriel