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

[Pekka Savola <pekkas at netcore.fi>]

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