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

From: gabriel montenegro <[email-masked]>
Date: Thu, 18 Jan 2007 00:42:37 -0800 (PST)

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 <[email-masked]>
To: gabriel montenegro <[email-masked]>; Geoff Mulligan <[email-masked]>; 6lowpan <[email-masked]>
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 

  <[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

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

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 18 Jan 2007 02:36:50 -0700

I think that is does clarify the point about deriving addresses, but i
still feel we need some sort of comment on dealing with icmp messages.

I'd like to hear from others.

Also do we feel that we have reached consensus on the issue of header
ordering?

	geoff

On Thu, 2007-01-18 at 00:42 -0800, gabriel montenegro wrote:
> 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.
> 
>    destination
> to this:
> To: gabriel montenegro <[email-masked]>; Geoff
> Mulligan <[email-masked]>; 6lowpan <[email-masked]>
> 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: gabriel montenegro 
>         Sent: Thursday, January 18, 2007 3:07 PM
>         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.
>         Comments? Am I missing something?
>         
>         -gabriel
>         
>         From: Geoff Mulligan <[email-masked]>
>         To: 6lowpan <[email-masked]>
>         Sent: Wednesday, January 17, 2007 10:36:52 PM
>         handling of ICMPv6 error messages.  Since the 6lowpan headers
>         may be
>         Here is my proposed text for a new section 12...
>         
>         12. Handling ICMPv6 messages
>         
>         and functions such as diagnostics.  There are two groups of
>         ICMPv6
>         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.
>         
>           
>         
>