Hi Alex, as you have noticed, RFC 4944 needs cleanup. We have already
discussed updating and/or replacing RFC 4944 within this WG.
Please see additional comments inline:
On Feb 18, 2009, at 3:44 AM, Alexandru Petrescu wrote:
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?
There is an ack request bit in the 15.4 header. Please see the
referenced 15.4 spec.
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?
A multicast address.
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.
You are correct. That's why RFC 4944 also specifies uncompressed IPv6
headers.
5. LoWPAN Adaptation Layer and Frame Format
Is this mandatory use in 15.4 IPv6 networks?
Yes. The adaptation layer also adds a protocol dispatch that is sorely
missing from the 15.4 header.
| 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].
Yes. Should be "Uncompressed IPv6 Header".
6. Stateless Address Autoconfiguration
This section defines how to obtain an IPv6 interface identifier.
So why is the section title misleading.
Not sure what you mean. One has to construct an IID somehow and this
section specifies how to obtain one from a 15.4 address.
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.
No. But you're right, the analogy is not a good one. 802.2. has 6-byte
addrs, while 15.4 has 8-byte EUI-64's.
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?
You're right. It should say something closer to what's in RFC 4862.
Specifically:
1. The left-most 'prefix length' bits of the address are those of
the link-local prefix.
2. The bits in the address to the right of the link-local prefix
are
set to all zeroes.
3. If the length of the interface identifier is N bits, the right-
most N bits of the address are replaced by the interface
identifier.
(Remove link-local to support arbitrary prefixes).
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)
Should be /10 with zeros padded as mentioned above.
> 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?
There is still debate within the 6LoWPAN group on this subject.
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.
When not using a mesh addressing header, MAC-layer broadcast is used
to support multicast.
What happens with the lost octet of a solicited-node IP multicast
address? (it has 3, and this uses only 2).
When using mesh addressing header, you only have the last 13 bits to
work with. Think of these bits as a possible optimization so that the
adaptation layer can optimize multicast delivery over multiple hops.
BTW, I don't believe we should be specifying L2-stuff like this within
the IETF. Much of the stuff in the RFC was there long before I got my
hands on it.
10. Header Compression
There is much published and in-progress standardization work on
header compression.
Yes, ROHC evolved...
And is still flow-based...
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).
Exactly right. Which is why we're actively working on a new HC
specification.
both the
Traffic Class and the Flow Label are zero;
So no qos and HC, ok?
Fixed in the new HC.
and the Next Header is
UDP, ICMP or TCP.
So no Mobile IPv6 and HC, ok?
Fixed in the new HC.
--
Jonathan Hui
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
