Hi Jonathan,
Jonathan Hui a écrit :
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.
Ok, I see, it would have been clearer if it said "be carried in data
frames for which..." instead of "be carried in frames for which...".
BEcause otherwise makes think the "data frames" are different than the
"frames 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?
A multicast address.
Which IP multicast address? The all-nodes multicast address? The
all-routers multicast address? Which scope (interface, link, site)?
A newly defined 'all-somethings' address? (rfc3513 lists some
possibilities).
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.
I think link-layer multicast capabilities are more missing than anything
else. More important than HC too and than mesh-under routing.
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.
95% of text in this section describes how to form the IID. I think it
would be better called "Forming an IID on 802.15.4" rather than
Stateless Address Autoconfiguration.
(the fact that rfc2464 calls its section 4 "Stateless Autoconfiguration"
is a misnomer which should be corrected, because (1) makes people think
it's about an address being autoconfigured statelessly - it's actually
an IID not an address, and (2) it can easily be misunderstood for
"Stateless Address Autoconfiguration" RFC4862 which is much more than
just forming an IID and involves messages being exchanged.)
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.
I fully agree with this 3rd point. An implementation does so.
I think this may be used to suggest correction to RFC2464 as well (it
requires the prefix to be 64bits, bottom of page 3, and I disagree, it
could be shorter). I think I will post separately see what people think
on the 6man list.
[...]
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.
This is what I'm thinking too.
But I don't know how to make it otherwise work. If IEEE doesn't offer a
multicast-capable link-layer, and if nobody else does, I'm afraid many
IPv6-based protocols simply won't work.
I think it could be too much work to modify every other protocol
(DHCPv6, Mobile IPv6, ND, SLAAC, OSPF, RIPng to name a few relying on
link-layer multicast) to work on such specific link-layer.
10. Header Compression There is much published and in-progress
standardization work on header compression.
Yes, ROHC evolved...
And is still flow-based...
Sounds as an inconvenient of it, but I don't see 'flow' mentioned in HC
(for other than Flow Label). I would have expected to see how HC is not
flow-based, or similar.
Also, I would have expected to see the MANET Packet Format, rfc5444,
ways of compressing IP addresses and prefixees.
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.
Oh I see, the HC draft, ok.
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
