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 PROTECTED]>
> To: 6lowpan <[email protected]>
> 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 protected]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
