Dear 6LoWPANers,
I have some comments and questions on RFC4944. I wrote these comments
while reading the RFC to get familiar with it. I don't know what are
the intentions of progressing the draft. For the record.
IEEE 802.15.4 defines four types of frames: beacon frames, MAC
command frames, acknowledgement frames, and data frames. IPv6
packets MUST be carried on data frames. Data frames may optionally
request that they be acknowledged. In keeping with [RFC3819], it is
recommended that IPv6 packets be carried in frames for which
acknowledgements are requested so as to aid link-layer recovery.
So IPv6 packets must be carried on data frames, and on frames for which
acks are requested. Are all data frames requesting acks? If not, what
distinguishes data frames requesting acks from data frames not
requesting acks?
2. A short destination address is included in the frame, and it MUST
match the broadcast address (0xffff).
What is the IP destination address in this case?
2. Even though the above space calculation shows the worst-case
scenario, it does point out the fact that header compression is
compelling to the point of almost being unavoidable. Since we
expect that most (if not all) applications of IP over IEEE
802.15.4 will make use of header compression, it is defined below
in Section 10.
This is dangerously approaching saying IP HC is a MUST for 15.4
networks. I disagree.
5. LoWPAN Adaptation Layer and Frame Format
Is this mandatory use in 15.4 IPv6 networks?
| 01 000001 | IPv6 - Uncompressed IPv6 Addresses |
or Uncompressed IPv6 headers (the full IPv6 headers are present)?
because later it says:
IPv6: Specifies that the following header is an uncompressed IPv6
header [RFC2460].
6. Stateless Address Autoconfiguration
This section defines how to obtain an IPv6 interface identifier.
So why is the section title misleading.
The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may
be based on the EUI-64 identifier [EUI64] assigned to the IEEE
802.15.4 device. In this case, the Interface Identifier is formed
from the EUI-64 according to the "IPv6 over Ethernet" specification
[RFC2464].
Is there an 802.3 layer on top of 802.15.4? This is good to clarify.
An IPv6 address prefix used for stateless autoconfiguration [RFC4862]
of an IEEE 802.15.4 interface MUST have a length of 64 bits.
Does this effectively forbid 54bit prefix lengths?
The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface
is formed by appending the Interface Identifier, as defined above, to
the prefix FE80::/64.
/64 or /10? (rfc3513.txt says Link-local unicast 1111111010
FE80::/10 2.5.6)
> 9. Multicast Address Mapping
>
The functionality in this section MUST only be used in a mesh-enabled
LoWPAN.
Yes, but it's not clear: will a mesh-enabled LoWPAN use route-over or
mesh-under routing?
The functionality in this section MUST only be used in a mesh-enabled
LoWPAN. An IPv6 packet with a multicast destination address (DST),
consisting of the sixteen octets DST[1] through DST[16], is
transmitted to the following 802.15.4 16-bit multicast address:
But I thought 802.15.4 wihtout adaptation layer doesn't have multicast
addresses.
What happens with the lost octet of a solicited-node IP multicast
address? (it has 3, and this uses only 2).
10. Header Compression
There is much published and in-progress standardization work on
header compression.
Yes, ROHC evolved...
10.1. Encoding of IPv6 Header Fields
By virtue of having joined the same 6LoWPAN network, devices share
some state. This makes it possible to compress headers without
explicitly building any compression context state. Therefore,
6LoWPAN header compression does not keep any flow state; instead, it
relies on information pertaining to the entire link. The following
IPv6 header values are expected to be common on 6LoWPAN networks, so
the HC1 header has been constructed to efficiently compress them from
the onset: Version is IPv6; both IPv6 source and destination
addresses are link local;
For this reason, 6LoWPAN HC may not be useful when the network is
connected to the Internet (src/dst addresses be global).
both the
Traffic Class and the Flow Label are zero;
So no qos and HC, ok?
and the Next Header is
UDP, ICMP or TCP.
So no Mobile IPv6 and HC, ok?
Alex
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
