Re: [6lowpan] questions about lowpan_nhc fields

"Colin O'Flynn" <coflynn@newae.com> Tue, 22 March 2011 19:06 UTC

Return-Path: <coflynn@newae.com>
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871A128C120 for <6lowpan@core3.amsl.com>; Tue, 22 Mar 2011 12:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9SRKWTkm7GC for <6lowpan@core3.amsl.com>; Tue, 22 Mar 2011 12:06:49 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 349A928C0F8 for <6lowpan@ietf.org>; Tue, 22 Mar 2011 12:06:49 -0700 (PDT)
Received: from net-93-145-126-30.cust.dsl.teletu.it ([93.145.126.30] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from <coflynn@newae.com>) id 1Q26wG-0004Ge-FK; Tue, 22 Mar 2011 15:08:21 -0400
From: Colin O'Flynn <coflynn@newae.com>
To: minister@dei.unipd.it, 6lowpan@ietf.org
References: <20110316181810.19202jt7x4xd1eio@mail.dei.unipd.it>
In-Reply-To: <20110316181810.19202jt7x4xd1eio@mail.dei.unipd.it>
Date: Tue, 22 Mar 2011 20:08:05 +0100
Message-ID: <000901cbe8c4$7ce13880$76a3a980$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acvos6s++tjlHtGHRl2FxAdONAJmsgAD+6kQ
Content-Language: en-ca
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - newae.com
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [6lowpan] questions about lowpan_nhc fields
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2011 19:06:50 -0000

Hello Giulio,

There are two levels of fragmentation, I think that might be causing
confusion?

IPv6 level fragmentation DOES keep the IPv6 headers between fragments, for
example see
http://www.tcpipguide.com/free/t_IPv6DatagramSizeMaximumTransmissionUnitMTUF
ragment-4.htm .

6LoWPAN level fragmentation DOES NOT keep the IPv6 headers between
fragments. 6LoWPAN only repeats the 6LoWPAN header between fragments.

The 6LoWPAN MTU is (at least) 1280 bytes. Any packet larger than fits in a
single 15.4 packet but smaller or equal to the 6LoWPAN MTU will be
fragmented at the 6LoWPAN layer. Anything larger than the 6LoWPAN MTU would
have to be fragmented at the IPv6 layer by the sender, and each of those
IPv6 fragments may have 6LoWPAN fragmentation applied.

Hope this is a lucid explanation, let me know if it doesn't make sense.

Regards,

  -Colin O'Flynn

-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of minister@dei.unipd.it
Sent: March 16, 2011 6:18 PM
To: 6lowpan@ietf.org
Subject: [6lowpan] questions about lowpan_nhc fields

Dear authors,
I would speak about 6lowPAN hc-15 draft document.
Section 4 describes the ipv6 next header compression and in 4.2 ipv6  
extension header encoding is shown.
So incidentally in a 802.15.4 127 byte long packet I could have a mesh  
header and a fragmentation header like RFC4944 describes; after those  
a lowpan_IPCH dispatch with in-line ipv6 fields, like it is shown in  
figure 1 on page 5. All those headers (RFC4944 and figure 1 ones) in a  
single 802.15.4 packet.
But figure 11 on page 14 shows that we could have other headers like  
in IPv6 (so-called extension-header), and they could be heavy like  
router header or they grows on-the-fly like hop-by-hop header.
So my questions are: do those extension headers have to be present in  
every fragment of an IPv6 packet? And if it is so, doesn't it seem  
like wasting a lot of space? Let's say that I want to send a message  
and I have to write entirely the IPv6 source and destination addresses  
and I want a routing header too, even with 4 addresses, I fill 80 out  
of 127 bytes only for addresses. Is this example right or I understand  
wrongly the document?  And after these considerations, is it necessary  
to change the rule to calculate the datagram size field in RFC4944  
fragmentation header?
   Best regards
     Giulio Ministeri
        from University of Padova, Italy

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan