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