IANA Last Call Comments:

Upon approval of this document IANA understands it must
complete two actions.

First, creation of a new registry called the "Internet
Protocol version 6 (IPv6) Low Power Personal Area Network
Parameters" will be created in the IANA Matrix at a location
to be determined later.

In this new registry two new subregistries will be created:

- IPv6 Low Power Personal Area Network Dispatch Type field

New registrations in this subregistry are done through IETF
Consensus only.

Initial values in the Dispatch Type subregistry are:

Bit Pattern Header Type
----------- ---------------------------------------
00 xxxxxx NALP - Not a LoWPAN frame
01 000001 IPv6 - uncompressed IPv6 Addresses
01 000010 LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6
01 000011
through reserved for future use
01 001111
01 010000 LOWPAN_BC0 - LOWPAN_BC0 broadcast
01 010001
through reserved for future use
01 111110
01 111111 ESC - Additional Dispatch byte follows

- IPv6 Low Power Personal Area Network Short Address Fields

New registrations in this subregistry are done through
IETF Consensus only.

Address
Range Description
------------------------------------ ----------------------------------
0000000000000000 to 0111111111111111 unicast addresses
1000000000000000 to 1001111111111111 multicast addresses
1010000000000000 to 1011111111111111 reserved for future assignment
1100000000000000 to 1101111111111111 reserved for future assignment
1110000000000000 to 1111111111111100 reserved for future assignment
1111111111111110 as defined in IEE 802.15.4
1111111111111111 broadcast address

The second action required by the approval of this document
is the creation of a port number, assigned from the User
Registered port number range, for UDP header compression in
IPv6 Low Power Personal Area Networks.

IANA understands that these are the only actions required
upon approval of this document.

IANA Last Call Comments:

Upon approval of this document IANA understands it must
complete two actions.

First, creation of a new registry called the "Internet
Protocol version 6 (IPv6) Low Power Personal Area Network
Parameters" will be created in the IANA Matrix at a location
to be determined later.

In this new registry two new subregistries will be created:

- IPv6 Low Power Personal Area Network Dispatch Type field

New registrations in this subregistry are done through IETF
Consensus only.

Initial values in the Dispatch Type subregistry are:

Bit Pattern Header Type
----------- ---------------------------------------
00 xxxxxx NALP - Not a LoWPAN frame
01 000001 IPv6 - uncompressed IPv6 Addresses
01 000010 LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6
01 000011
through reserved for future use
01 001111
01 010000 LOWPAN_BC0 - LOWPAN_BC0 broadcast
01 010001
through reserved for future use
01 111110
01 111111 ESC - Additional Dispatch byte follows

- IPv6 Low Power Personal Area Network Short Address Fields

New registrations in this subregistry are done through
IETF Consensus only.

Address
Range Description
------------------------------------ ----------------------------------
0000000000000000 to 0111111111111111 unicast addresses
1000000000000000 to 1001111111111111 multicast addresses
1010000000000000 to 1011111111111111 reserved for future assignment
1100000000000000 to 1101111111111111 reserved for future assignment
1110000000000000 to 1111111111111100 reserved for future assignment
1111111111111110 as defined in IEE 802.15.4
1111111111111111 broadcast address

The second action required by the approval of this document
is the creation of a port number, assigned from the User
Registered port number range, for UDP header compression in
IPv6 Low Power Personal Area Networks.

IANA understands that these are the only actions required
upon approval of this document.

[Ballot discuss]
> This document assumes that a PAN maps to a specific IPv6 link, hence
> it implies a unique prefix.  Knowledge of the 16-bit PAN ID (e.g., by
> including it in the IEEE 802.15.4 headers) would enable automatically
> mapping it to the corresponding IPv6 prefix.  One possible method is
> to concatenate the 16 bits of PAN ID to a /48 in order to obtain the
> 64-bit link prefix.  Whichever method is used, the assumption in this
> document is that a given PAN ID maps to a unique IPv6 prefix.  This

Please explain how this relates to regular IPv6 prefix configuration
methods (such as RAs) and whether this prevents the configuration
of multiple prefixes on the same link.

> As usual, hosts learn IPv6 prefixes via router advertisements as per
> [I-D.ietf-ipv6-2461bis].  The working group may pursue additional
> mechanisms as well.

Please delete the second sentence. Further work is always
possible, but you have to provide an unambigious definition
of what IPv6 over 802.15.4 means in this document.

> Additionally, support for mapping of IPv6 multicast addresses MAY be
> provided as per Section 9.  A full specification of such
> functionality is out of scope of this document.

This seems to suggest that there are two ways to implement multicast
over 802.15.4. Let me quote RFC 1958, architectural principles of the
Internet: "3.2 If there are several ways of doing the same thing,
choose one."  Specifically, there is no negotiation whether multicast
is implemented via broadcast or the suggested scheme, so how would
node be able to determine what they should be sending? Also, the
description in Section 9 seems to indicate that it is incomplete.

One way to resolve this is to remove the second approach, i.e.,
Section 9. However, this implies that all nodes within a 802.15.4
network will need to wake up when one of them is called upon
in, say, Neighbor Solicitation.

> datagram_size:  This 11 bit field encodes the size of the entire IP
>  payload datagram.  The value of datagram_size SHALL be the same
>  for all link fragments of an IP payload datagram.  For IPv6, this
>  SHALL be 40 octets (the size of the uncompressed IPv6 header) more
>  than the value of Payload Length in the IPv6 header [RFC2460].
>  Typically, this field needs to encode a maximum length of 1280
>  (IEEE 802.15.4 link MTU as defined in this document), and as much
>  as 1500 (the default maximum IPv6 packet size if IPv6
>  fragmentation is in use).  Therefore, this field is 11 bits long,
>  which works in either case.

The latter part seems incorrect. If IPv6 fragmentation is in use,
the recommended minimum packet size from RFC 2460 is indeed 1500
bytes. However, each individual IPv6 packet fragment carries a
payload length field <= path MTU, i.e., in this case 1280 or
smaller.

[Ballot discuss]
> This document assumes that a PAN maps to a specific IPv6 link, hence
> it implies a unique prefix.  Knowledge of the 16-bit PAN ID (e.g., by
> including it in the IEEE 802.15.4 headers) would enable automatically
> mapping it to the corresponding IPv6 prefix.  One possible method is
> to concatenate the 16 bits of PAN ID to a /48 in order to obtain the
> 64-bit link prefix.  Whichever method is used, the assumption in this
> document is that a given PAN ID maps to a unique IPv6 prefix.  This

Please explain how this relates to regular IPv6 prefix configuration
methods (such as RAs) and whether this prevents the configuration
of multiple prefixes on the same link.

> As usual, hosts learn IPv6 prefixes via router advertisements as per
> [I-D.ietf-ipv6-2461bis].  The working group may pursue additional
> mechanisms as well.

Please delete the second sentence. Further work is always
possible, but you have to provide an unambigious definition
of what IPv6 over 802.15.4 means in this document.

> Additionally, support for mapping of IPv6 multicast addresses MAY be
> provided as per Section 9.  A full specification of such
> functionality is out of scope of this document.

This seems to suggest that there are two ways to implement multicast
over 802.15.4. Let me quote RFC 1958, architectural principles of the
Internet: "3.2 If there are several ways of doing the same thing,
choose one."  Specifically, there is no negotiation whether multicast
is implemented via broadcast or the suggested scheme, and the
descritption in Section 9 seems to indicate that it is incomplete.

One way to resolve this is to remove the second approach, i.e.,
Section 9. However, this implies that all nodes within a 802.15.4
network will need to wake up when one of them is called upon
in, say, Neighbor Solicitation.

> datagram_size:  This 11 bit field encodes the size of the entire IP
>  payload datagram.  The value of datagram_size SHALL be the same
>  for all link fragments of an IP payload datagram.  For IPv6, this
>  SHALL be 40 octets (the size of the uncompressed IPv6 header) more
>  than the value of Payload Length in the IPv6 header [RFC2460].
>  Typically, this field needs to encode a maximum length of 1280
>  (IEEE 802.15.4 link MTU as defined in this document), and as much
>  as 1500 (the default maximum IPv6 packet size if IPv6
>  fragmentation is in use).  Therefore, this field is 11 bits long,
>  which works in either case.

The latter part seems incorrect. If IPv6 fragmentation is in use,
the recommended minimum packet size from RFC 2460 is indeed 1500
bytes. However, each individual IPv6 packet fragment carries a
payload length field <= path MTU, i.e., in this case 1280 or
smaller.

[Ballot discuss]
section 5.3:

The length of the datagram_tag in the fragmentation mechanism. There have been some concerns that 10bits are not sufficient for the physical layers being defined for 802.15.4. Until the WG has convinced itself that the number of bits are sufficient to avoid wraps in sequence numbers this should not be published.

In case the datagram_tag field wraps within the timeframe (maximum 60s) payload fragments are kept in the reassembly buffer erronous reassembly may occur creating corrupt IP packets. This occurs due to loss of a fragment and the data being inserted into this IP packets are belonging to a later transmitted IP packet which has the same datagram_tag and offset but after it having wrapped. That the fragment being inserted will have the same offset is likely. In addition the may continue to happen due to that as long as there appear new packets with the same datagram_tag within the reassambly time they will continue to steal fragments from the later comming packet.


Section 10.1:

  By virtue of having joined the same 6LoWPAN network, devices share
  some state.  This makes it possible to compress headers even in the
  absence of the customary context-building phase. 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
  packet length can be inferred either from layer two ("Frame Length"
  in the IEEE 802.15.4 PPDU) or from the "datagram_size" field in the
  fragment header (if present); both the Traffic Class and the Flow
  Label are zero; and the Next Header is UDP, ICMP or TCP.
 
Currently this is written such as that one get the impression that these assumptions always will be true. Instead as it seems it should be interpret, in case the fields has the following values gains in HC can be made.

The text is also confusing the reader if there exist a context state or not. For example:

      Preliminary context is often required.  If so, it is highly
      desirable to allow building it by not relying exclusively on the
      in-line negotiation phase.  For example, if we assume there is
      some manual configuration phase that precedes deployment (perhaps
      with human involvement), then one should be able to leverage this
      phase to set up context such that the first packet sent will
      already be compressed.

Or

  By virtue of having joined the same 6LoWPAN network, devices share
  some state.  This makes it possible to compress headers even in the
  absence of the customary context-building phase.

There is also confusion about if several flows can be handled. Primarily due to the following:

      Existing work assumes that there are many flows between any two
      devices.  Here, we assume that most of the time there will be only
      one flow, and this allows a very simple and low context flavor of
      header compression.

Please clarify that the compression is done totally without context and thus can handle any number of flows.


Section 10.2:

      UDP source port (bit 0):
        0: Not compressed, carried "in-line" (Section 10.3.2)
        1: Compressed to 4 bits.  The actual 16-bit source port is
            obtained by calculating: P + short_port value.  P is a
            predetermined port number with value TBD.  The short_port is
            expressed as a 4-bit value which is carried "in-line"
            (Section 10.3.2)
           
P is to be assigned by IANA.

This document requests an IANA assignment of a port number P, for use
  with UDP header compression (Section 10.2).  This port number P is
  used as the base to which the "short_port" 4-bit values are added in
  order to obtain the actual UDP port used.


Why does one need to have IANA to assign P? Do one accept that special lowpan application to be assigned numbers in the range p..p+15? I am lacking an explanation on how this should work.

[Ballot comment]
Section 3, last paragrpah:
The working group may pursue additional
  mechanisms as well.
 
Is this the right document to state a possible direction of a WG?

Section 10.

Unfortuntate that this document wasn't announced on the ROHC WG list during its WGL last call. Based on that the description seems somewhat to thin to be easily implementable. I would propose that we delay the approval, update the draft and send it for an explicit review in ROHC.

[Ballot discuss]
Section 10.1:

  By virtue of having joined the same 6LoWPAN network, devices share
  some state.  This makes it possible to compress headers even in the
  absence of the customary context-building phase. 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
  packet length can be inferred either from layer two ("Frame Length"
  in the IEEE 802.15.4 PPDU) or from the "datagram_size" field in the
  fragment header (if present); both the Traffic Class and the Flow
  Label are zero; and the Next Header is UDP, ICMP or TCP.
 
Currently this is written such as that one get the impression that these assumptions always will be true. Instead as it seems it should be interpret, in case the fileds has the following values gains in HC can be made.

Section 10.

There is a lack of motivation why this header compression is applicable to the IP encapsulation provided in this spec. Also the assumption about what usage behavior and the flows sent above the encapsulation is missing.

Section 10.

Lack of rules for how to handle in case there are more than a single flow.
There need to rules on how to determine if the context should be used or not.

Section 10.2:

      UDP source port (bit 0):
        0: Not compressed, carried "in-line" (Section 10.3.2)
        1: Compressed to 4 bits.  The actual 16-bit source port is
            obtained by calculating: P + short_port value.  P is a
            predetermined port number with value TBD.  The short_port is
            expressed as a 4-bit value which is carried "in-line"
            (Section 10.3.2)
           
P is to be assigned by IANA.

This document requests an IANA assignment of a port number P, for use
  with UDP header compression (Section 10.2).  This port number P is
  used as the base to which the "short_port" 4-bit values are added in
  order to obtain the actual UDP port used.


Why does one need to have IANA to assign P? Do one accept that special lowpan application to be assigned numbers in the range p..p+15? I am lacking an explanation on how this should work.

[Ballot comment]
(Updated with comments from Gen-ART review)

> 5.3.  Fragmentation Type and Header

The datagram tag (used for fragment reassembly) cycles after
1024 values, and the reassembly timeout is 60 seconds.
I'd like to see a calculation that the tag will never cycle
in less than 60 seconds. That doesn't seem like a long
time for sending a thousand packets. Maybe ZigBee is
just plain slow?

> 10.  Header Compression
>
>  There is much published and in-progress standardization work on
>  header compression.

I'd like to see a few words about why ROHC is inapplicable.

>      Traffic Class and Flow Label (bit 4):
>        0: not compressed, full 8 bits for Traffic Class and 20 bits
>            for Flow Label are sent

What's the rationale for not compressing them? They are identical
in all packets of a given flow, so ideal candidates for compression.

From Gen-ART review by Joel Halpern:

        I don't know that I have ever seen a document before that says "thou shalt not extend this."  (Section 5, last sentence before 5.1, "All headers used in LOWPAN adaptation layer SHALL be defined in this format document.")
        The fragmentation technique sends an offset that is in multiple of 8 bytes.  It would be sensible to say that all fragments except the last SHOULD (MUST?) be multiple of eight bytes, so that the fragment offset works well.  (section 5.3)
        At the beginning of section 10.1 on Encoding IPv6 Header fields, the wording is slightly misleading.  The wording says "The following common IPv6 header values may be compressed from the onset..."  I would suggest instead "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."

[Ballot comment]
(Updated with comments from Gen-ART review)

> 5.3.  Fragmentation Type and Header

The datagram tag (used for fragment reassembly) cycles after
1024 values, and the reassembly timeout is 60 seconds.
I'd like to see a calculation that the tag will never cycle
in less than 60 seconds. That doesn't seem like a long
time for sending a thousand packets. Maybe ZigBee is
just plain slow?

> 10.  Header Compression
>
>  There is much published and in-progress standardization work on
>  header compression.

I'd like to see a few words about why ROHC is inapplicable.

>      Traffic Class and Flow Label (bit 4):
>        0: not compressed, full 8 bits for Traffic Class and 20 bits
>            for Flow Label are sent

What's the rationale for not compressing them? They are identical
in all packets of a given flow, so ideal candidates for compression.

From Gen-ART review by Joel Halpern:

        I don't know that I have ever seen a document before that says "thou shalt not extend this."  (Section 5, last sentence before 5.1, "All headers used in LOWPAN adaptation layer SHALL be defined in this format document.")
        The fragmentation technique sends an offset that is in multiple of 8 bytes.  It would be sensible to say that all fragments except the last SHOULD (MUST?) be multiple of eight bytes, so that the fragment offset works well.  (section 5.3)
        At the beginning of section 10.1 on Encoding IPv6 Header fields, the wording is slightly misleading.  The wording says "The following common IPv6 header values may be compressed from the onset..."  I would suggest instead "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."

[Ballot comment]
The following two Informative References do not seem to be used:

    [I-D.ietf-ipngwg-icmp-v3]
              Conta, A., "Internet Control Message Protocol (ICMPv6) for
              the Internet Protocol Version  6 (IPv6) Specification",
              draft-ietf-ipngwg-icmp-v3-07 (work in progress),
              July 2005.

  [I-D.ietf-ipv6-node-requirements]
              Loughney, J., "IPv6 Node Requirements",
              draft-ietf-ipv6-node-requirements-11 (work in progress),
              August 2004.

[Ballot comment]
I'm waiting for a a Gen-ART review, so may have other questions
later. But I'd like to see comments on these before I ballot:

> 5.3.  Fragmentation Type and Header

The datagram tag (used for fragment reassembly) cycles after
1024 values, and the reassembly timeout is 60 seconds.
I'd like to see a calculation that the tag will never cycle
in less than 60 seconds. That doesn't seem like a long
time for sending a thousand packets. Maybe ZigBee is
just plain slow?

> 10.  Header Compression
>
>  There is much published and in-progress standardization work on
>  header compression.

I'd like to see a few words about why ROHC is inapplicable.

>      Traffic Class and Flow Label (bit 4):
>        0: not compressed, full 8 bits for Traffic Class and 20 bits
>            for Flow Label are sent

What's the rationale for not compressing them? They are identical
in all packets of a given flow, so ideal candidates for compression.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Yes. Geoff Mulligan will be the Document Shepherd for the document.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes. The document has had a significant review by the working group
and by the Document Shepherd and we have reached consensus on the
document and there are no concerns about the extent of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No. The document does not need further review from other areas.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

No. The Document Shepherd does not have any concerns about this
document.
All concerns were raised on the mailing list and have been dealt with.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

We have reached very strong broad consensus on this document. There
have been no dissenting opinions raised during the last review or during
the WGLC.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No. No apeals have been threatened or raised.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. I ran the document through idnits and we corrected the problems
identified.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes and all normative references in the document are to either
existing RFCs or to documents that are in the final stages of
standardization, i.e. already in IESG approval or are in the RFC
editor's queue.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with
the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?

Yes. The document does contain an IANA consideration section and new
IANA registries are clearly identified and properly defined.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no sections of the document that use a formal language.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
6LoWPAN is specification describing how to utilize
IPv6 on top of low power, low data rate, low cost personal area
networks. These networks today being built using IEEE 802.15.4
standard radios. These radios have an extremely limited frame
size which makes it necessary to define an adaptation layer to
support link layer fragmentation and reassembly. Additionally
since these networks utilize low power transmission it is
necessary for the adaptation layer to support network layer mesh
capabilities. This specification defines the header format for
this adaptation layer.

Working Group Summary
The working group reached consensus on this document.

Document Quality
There are at least 6 independent implementations of this protocol
being worked on and all concerns raised during the review and
WGLC have been addressed.

Personnel
Geoff Mulligan is the Document Shepherd.
Mark Townsley is the responsible Area Director.