Re: [6lowpan] Slight problem with format document

["Daniel Park" <[e-mail]>]

It seems a bit implementation issue. Our format document defines four classes:

[1] Prefix In-line IID In-line
[2] Prefix In-line IID compressed
[3] Prefix compressed IID In-line
[4] Prefix compressed IID compressed

Most assumtion in our scenario as of today is [4]. It means IPv6
source and destination belong to link-local scope. In your assumtion,
perhaps, [1] and [2] are appropriate. In that sense, 6lowpan
adoptation layer seems not meaningful. Also, 6lowpan header
compression is only applied for 802.15.4 link due to the tiny
bandwidth.

Daniel

On 1/18/07, Mario Mao <[e-mail]> wrote:
>
> 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 <[e-mail]>
> To: 6lowpan <[e-mail]>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>
> ________________________________
>
>
> _______________________________________________
> 6lowpan mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>
> _______________________________________________
> 6lowpan mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>


-- 


Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

_______________________________________________
6lowpan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/6lowpan