On Thu, 15 Feb 2007, The IESG wrote:
The IESG has received a request from the IPv6 over Low power WPAN WG
(6lowpan) to consider the following document:
- 'Transmission of IPv6 Packets over IEEE 802.15.4 Networks '
<draft-ietf-6lowpan-format-10.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2007-03-01. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-10.txt
Sorry for slightly missing the LC deadline. Some comments below.
A couple of meta-points:
- the specification for Mesh type networks seems incomplete, and the
draft recognizes it as such. It's not clear to me what's the
benefit of including that operational mode in the first place given
that it's not likely to interoperate.
- are all nodes expected to support both 'short address' and long
address addressing types, i.e., having both on the same link will
interoperate? There are no requirements about this but those may be
in the IEEE specification. I assume supporting both is required.
- Security Considerations could mention RFC3041 and possibly
short-from addresses in the first paragraph.
- There appears to be no mandatory-to-implement security model for
mesh-type networks. (Well, given that there isn't even a good
specification of how mesh-type network would work, it's no
surprise..)
A few specific comments:
If a link fragment is received that overlaps another fragment as
identified above and differs in either the size or datagram_offset of
the overlapped fragment, the fragment(s) already accumulated in the
reassembly buffer SHALL be discarded.
==> this is similar to IP reassembly, but suffers from overlapping
fragment attacks discussed in RFC 1858. Given the more limited attack
vector (the same IP link), this might be acceptable. Has this attack
been discussed? Were alternatives (e.g., 'discard new' instead of
'replace old') considered?
6. Stateless Address Autoconfiguration
==> no mention is made regarding IPv6 privacy addressing (RFC 3041, or
a bis draft). Is it applicable as well? The last sentence at the end
of section 8 seems to suggest so.
Thus, the following
common IPv6 header values may be compressed from the onset: Version
is IPv6; both IPv6 source and destination addresses are link local;
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);
==> The address compression part is not clear. Are you saying
that only link-local addresses can be compressed using this
methodology? Do you envision that applications run in a PAN use
link-local or some other addresses? I'd have major architectural
objections to using link-locals in applications due to their ambiguity
and difficulties with zone index handling in the apps.
(On the next page with actual technical details of compression it
becomes clearer how compression can be used in various scenarios.
Maybe the list above and partial details therein may be unnecessary.)
Range 2, 100xxxxxxxxxxxxx: Bits 0,1 and 2 SHALL follow this pattern
if the 16-bit address is a multicast address (see Section 9).
This leaves 13 bits for the actual multicast address.
==> if a multicast-based short address were to be used as a
source address, behaviour would be unspecified. Is that OK?
More generally, as the type of the address is deep inside the 64-bit
IID, it's not clear how well nodes are able to recognize it in any
case. Wouldn't it be perfectly legitimate for a node to manually
configure an interface identifier which would be indistinguishable
from a short address EID? Is it necessary to be able to tell
short-address EIDs and other EIDs apart somehow?
editorial
---------
==> the same comment wrt 'personal' in LoWPAN as for the goals draft
applies here. It's not obvious to me what's 'personal' in this
specification or technology.
Abstract
This document describes the frame format for transmission of IPv6
packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on IEEE 802.15.4 networks.
Additional specifications include a simple header compression scheme
using shared context and provisions for packet delivery in IEEE
802.15.4 meshes.
==> 'additional specifications' probably refers to other documents,
yet section 10 appears to define at least something related to header
compression. Is the Abstract up-to-date?
| 01 111111 | ESC - Additional Dispatch byte follows |
+----------+-----------------------------------------------+
==> off-by-two at the bottom of the table..
datagram_size: This 11 bit field encodes the size of the entire IP
payload datagram.
==> .. 'in octets' ? You don't specify the unit..
Next Header (bits 5 and 6):
00: not compressed, full 8 bits are sent
01: UDP
10: ICMP
11: TCP
==> s/ICMP/ICMPv6/ -- you probably refer to protocol=58 instead of
protocol=1 ? (the same later in the section)
15.2. Informative References
[I-D.ietf-ipngwg-icmp-v3]
[I-D.ietf-ipv6-node-requirements]
==> these have been published in RFCs (but neither is actually used in
the body of the text, so could be fixed and added or removed
completely).
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf