Re: Last Call: draft-ietf-6lowpan-format (Transmission of IPv6 Packets over IEEE 802.15.4 Networks) to Proposed Standard

[Pekka Savola <[e-mail]>]

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
> [e-mail] mailing lists by 2007-03-01. Exceptionally,
> comments may be sent to [e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf