Subject: Re: [6lowpan] Slight problem with format document

From: gabriel montenegro <[email-masked]>
Date: Wed, 17 Jan 2007 23:07:28 -0800 (PST)

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 <[email-masked]>
To: 6lowpan <[email-masked]>
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

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

---

From: "Daniel Park" <[email-masked]>
Date: Thu, 18 Jan 2007 16:42:08 +0900

Agree with Gabriel's opinion. ICMPv6 is one of next header of IPv6
header, thus its processing will take place after the 6lowpan layer
delivers packets to the IPv6 node. Hence I don't think we need to
spell out this aspect in the 6lowpan format document.

Daniel

-- 

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

---

From: Mario Mao <[email-masked]>
Date: Thu, 18 Jan 2007 15:51:09 +0800

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

  -gabriel

  ----- Original Message ----
  From: Geoff Mulligan <[email-masked]>
  To: 6lowpan <[email-masked]>
  Sent: Wednesday, January 17, 2007 10:36:52 PM
  Subject: [6lowpan] Slight problem with format document

------------------------------------------------------------------------------

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 18 Jan 2007 00:57:00 -0700

Gabriel,
  If a node within a 6lowpan network receives a packet with a ttl of 1
won't it send back an icmp error message if it was supposed to forward
the packet, either if you were routing between 6lowpan nodes or between
6lowpan networks. Also couldn't an intermediate node send back a
"parameter problem" icmp message.

  And since these are being implemented on micro-controllers is it
strictly true that the layer separation is completely observed.  I could
see someone implementing a stack where you would not waste the limited
ram space to uncompress the ip header and that the ip layer would deal
with and understand the compressed headers and in this case the
transport header then might still be compressed.

Additionally I think that it is necessary to clarify if the checksum is
run over the compressed or uncompressed ip pseudo header.

I think for sake of clarity one short section (I may have been wordy)
isn't bad, unless it is just wrong.

	geoff

---

From: "Daniel Park" <[email-masked]>
Date: Thu, 18 Jan 2007 17:05:22 +0900

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 <[email-masked]> 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
>
>
> ________________________________
>
>

--

---

From: Mario Mao <[email-masked]>
Date: Thu, 18 Jan 2007 17:44:27 +0800

To Daniel:

Thanks for you tips.

However, I believe the compression issue is not just for implementation. Thinking about the reason why we need to build IPv6 upper  lowpan node, there is high possibility of global scope cummnication. In this scenario, and considering the format defination, the class [1] and [4] could appear at the same time.

For example, one remote controll center want to access an lowpan node, they would use IPv6 global address to communicate. When the IP packet reach to 6lowpan gateway, this routing node would redeliever it to the internal lowpan node. Now, the adaptation layer of the gateway should use class [1] and [4] for destination address compression and class [1] and [3] for source address. That's also the scenario of my assumption [1].

Is it better to clarify all possible situation? 

To Gabriel:

I think the tiny literal change would work, thanks. 

Regards,

Mario

---

From: "Daniel Park" <[email-masked]>
Date: Fri, 19 Jan 2007 01:24:21 +0900

Mario,

My comment are inline:

> Is it better to clarify all possible situation?

If we are considering global communication, there is no common prefix
between source address and destionation address comparing with
link-local addresses [fe80::/64], thus [1] or [3] is in use. In that
sense, 6lowpan header compression is less meaningful than link-local
communication. Or need more study on this case.

Daniel

<snip>