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