Subject: [6lowpan] Slight problem with format document

From: Geoff Mulligan <[email-masked]>
Date: Wed, 17 Jan 2007 23:36:52 -0700

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

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 18 Jan 2007 02:20:51 -0800 (PST)

And I remember there was discussion about this being too much
implementation detail when we added it. Other thoughts:

- this is at least relevant, being squarely within the lowpan layer
- ICMP processing does not seem nearly as relevant
- no IP-over-foo document deals with ICMP processing, so we should have a very
  good reason to do so here
- it is way past time to do further tweakings. let's only do further
  tweakings *after* moving to IESG.

and yes, we have consensus, we've had it for several days now. option 2 
from carsten's email was discussed, i suggested some text along those lines,
but finally Phil suggested it better be left out and pointed out that the current text
already allows us to define different behavior in the future.

And yes, I've already taken care of the superfluous note in the rev-09 (just now
submitted).

Let's please move on to IESG as soon as it appears on the repositories.

tnx,

-gabriel

----- Original Message ----
From: Geoff Mulligan <[email-masked]>
To: gabriel montenegro <[email-masked]>
Cc: 6lowpan <[email-masked]>
Sent: Thursday, January 18, 2007 1:45:16 AM
Subject: Re: [6lowpan] Slight problem with format document

I guess that I see your point but if we are not going to talk about
implementation details, why do we do so at the end of section 5.3.  It
seems that much of that is implementation dependent.

Also is the Note: in section 5 right before 5.1 actually necessary.

    geoff

On Thu, 2007-01-18 at 01:00 -0800, gabriel montenegro wrote:
> TTL (rather "Hop Count") of 1? Sure. The IPv6 layer handles that, not
> lowpan.
> Intermediate? No. ICMP is an IPv6 function. Intermediate nodes (as in
> a lowpan mesh)
> must not interfere with this. Now, if we wanted to define a lowpan
> layer error
> notification mechanism (analogous to ICMP at the IP layer), we could.
> But that's
> not ICMP, and I'd argue that we should define that in a separate draft
> later on
> (perhaps as part of forthcoming mesh routing specifications).
> 
> Sure, layering may be relaxed for optimization reasons. But this is
> nothing
> new: it's done today in optimized implementation regardless of lowpan.
> Still,
> the conceptual model holds, so those are implementation details we
> shouldn't
> be concerned about in this particular document. 
> 
> -gabriel
> 
> ----- Original Message ----
> From: Geoff Mulligan <[email-masked]>
> To: gabriel montenegro <[email-masked]>
> Cc: 6lowpan <[email-masked]>
> Sent: Wednesday, January 17, 2007 11:57:00 PM
> Subject: Re: [6lowpan] Slight problem with format document
> 
> 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
> 
> 
> 
> On Wed, 2007-01-17 at 23:07 -0800, gabriel montenegro wrote:
> > 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
> > 
> > encoding headers will be lost and the recipient would have no
> ability
> > to