--- Vipul Gupta <[EMAIL PROTECTED]> wrote:
> > On Oct 18, 2005, at 11:41 AM, gabriel montenegro wrote: > > --- Vipul Gupta <[EMAIL PROTECTED]> wrote: > >> 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? > > > > 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. 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 _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
