The following IESG comments appear editorial to me. They do need to
be addressed, though.
Any takers?
Gruesse, Carsten
#################################
* Prefix issue
Jari Arkko:
Discuss [2007-03-08]:
> 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.
#################################
* Multicast issue
> 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.
#################################
* Incorrect, but inconsequential statement...
> 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.
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
