Re: [6lowpan] Slight problem with format document
gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Thu, 18 January 2007 08:42 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Sr1-0005yW-Sm; Thu, 18 Jan 2007 03:42:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Sr0-0005yO-O8 for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 03:42:38 -0500
Received: from web81910.mail.mud.yahoo.com ([68.142.207.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Sr0-0002o9-2E for 6lowpan@lists.ietf.org; Thu, 18 Jan 2007 03:42:38 -0500
Received: (qmail 55715 invoked by uid 60001); 18 Jan 2007 08:42:37 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=TQjHHIonzuVxuHy/ds0Ql7cdoANVIQDOf2pUbywZbgzPW5LNjlgZoGbOwZK8mTD/LNznpzcOwLrC115QcjWBXcIkD8l3ypOprKMfAy89qcMSdZEK8rnm2ICeTd5+UGuIIT4x+4oCtnsqlzeHkcgE3SrYf0PftMOtzUv+R2xs4Bw= ;
Message-ID: <20070118084237.55713.qmail@web81910.mail.mud.yahoo.com>
Received: from [24.16.90.95] by web81910.mail.mud.yahoo.com via HTTP; Thu, 18 Jan 2007 00:42:37 PST
Date: Thu, 18 Jan 2007 00:42:37 -0800
From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [6lowpan] Slight problem with format document
To: Mario Mao <mariomao@gmail.com>, Geoff Mulligan <geoff@mulligan.com>, 6lowpan <6lowpan@lists.ietf.org>
MIME-Version: 1.0
X-Spam-Score: 0.9 (/)
X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96
Cc:
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0101021204=="
Errors-To: 6lowpan-bounces@ietf.org
Comment on this: "In a word, 6lowpan node could only compress the IID that derives from IEEE 802.15.4 MAC address. I think that point should be emphasized in draft, isn't it?" I think this draft talking about IPv6 over 802.15.4, "link-layer" refers to the underlying 802.15.4 link-layer, so the point above seems superfluous. Ok, in the interest of clarifying, I've tentatively changed this in section 10.1: the IPv6 bottom 64 bits can be inferred from the layer two source and destinationto this: the IPv6 interface identifiers (bottom 64 bits) for the source or destination addresses can be inferred from the layer two source and destination addresses (of course, this is only possible for interface identifiers derived from an underlying 802.15.4 MAC address) Does this work? -gabriel ----- Original Message ---- From: Mario Mao <mariomao@gmail.com> To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>; Geoff Mulligan <geoff@mulligan.com>; 6lowpan <6lowpan@lists.ietf.org> Sent: Wednesday, January 17, 2007 11:51:09 PM Subject: Re: [6lowpan] Slight problem with format document DIV { MARGIN:0px;} I agree with gabriel, there is no interference between header compression and ICMP. However, I believe two points should be noted which may cause information loss. 1. If the processing node is lowpan gateway/router and the sent packet comes from Internet but not originates by the gateway/router itself, the IID of IP source address shouldn't be compressed. 2. If the IP destination isn't an "on-link" node (that means the destination is more than one hop away from source node), the IID of IP destination address shouldn't be compressed. In a word, 6lowpan node could only compress the IID that derives from IEEE 802.15.4 MAC address. I think that point should be emphasized in draft, isn't it? Regards, Mario ----- Original Message ----- From: gabriel montenegro To: Geoff Mulligan ; 6lowpan Sent: Thursday, January 18, 2007 3:07 PM Subject: Re: [6lowpan] Slight problem with format document Is this even necessary to be said? ICMP msgs will never be sent by intermediate nodes in a lowpan mesh, but only by the IPv6 end nodes as part of normal IPv6 processing. This processing takes place after the lowpan layer delivers packets to the IPv6 stack. So by the time the IPv6 stack gets the packet, it will have been decompressed. This is the same for lowpan header compression or any other type of header compression. So I wonder if the text below is needed. It would be needed if the entity sending back ICMP messages was the lowpan layer. Yes, it would see compressed headers. But the entity is the IPv6 stack, which does not see those compressed headers. Comments? Am I missing something? -gabriel ----- Original Message ---- From: Geoff Mulligan <geoff@mulligan.com> To: 6lowpan <6lowpan@lists.ietf.org> Sent: Wednesday, January 17, 2007 10:36:52 PM Subject: [6lowpan] Slight problem with format document While reviewing the format document I realized that we didn't describe handling of ICMPv6 error messages. Since the 6lowpan headers may be compressed it is necessary to uncompress the original IP and transport headers before sending the ICMP error message. Here is my proposed text for a new section 12... 12. Handling ICMPv6 messages ICMPv6 (RFC2463) is used to report errors and carry IP layer information and functions such as diagnostics. There are two groups of ICMPv6 messages: error messages and informational messages. Each message consists of a type field (if the high order bit is 0 it is an error message), a code and checksum field. These fields are followed by the ICMPv6 message body. For ICMPv6 error messages (Type <128) the message body shall contain as much of the original (offending) IP message without exceeded the minimum IPv6 MTU. As described in the preceding section (Header Compression), the original IPv6 and Transport (TCP or UDP) headers may be compressed via HC1 and HC2 encoding. So that the destination node of an ICMPv6 error message can properly process the message the source node must decompress the IPv6 and transport headers before sending the ICMPv6 message. This is necessary because the original MAC addresses and the HC1 and HC2 encoding headers will be lost and the recipient would have no ability to reconstruct the original message nor compute the proper checksum. The ICMPv6 message itself is carried inside and IPv6 packet and this packet may be transmitted over the 6LoWPAN network utilizing header compression. ICMPv6 messages that are larger than the available payload of the 6LoWPAN network will need to be fragmented. Assuming the maximum frame overhead, maximum link layer security and including a 6LoWPAN Mesh Header, Fragmentation Header and Dispatch Header, sending the uncompressed IPv6 and transport headers should still allow for 25 octets of the original packet payload. Packets using short addresses, no security, and just a 6LoWPAN Dispatch header will be able to carry 61 octets of the original packet. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan
- [6lowpan] Slight problem with format document Geoff Mulligan
- Re: [6lowpan] Slight problem with format document gabriel montenegro
- Re: [6lowpan] Slight problem with format document Daniel Park
- Re: [6lowpan] Slight problem with format document Mario Mao
- Re: [6lowpan] Slight problem with format document Geoff Mulligan
- Re: [6lowpan] Slight problem with format document Daniel Park
- Re: [6lowpan] Slight problem with format document gabriel montenegro
- Re: [6lowpan] Slight problem with format document gabriel montenegro
- Re: [6lowpan] Slight problem with format document Geoff Mulligan
- Re: [6lowpan] Slight problem with format document Mario Mao
- Re: [6lowpan] Slight problem with format document Geoff Mulligan
- Re: [6lowpan] Slight problem with format document gabriel montenegro
- Re: [6lowpan] Slight problem with format document Daniel Park