[6lowpan] Fw: Your IETF LC comments on draft-ietf-6lowpan-format-11.txt

[gabriel montenegro <[e-mail]>]

This was my message to try to address Jari's comments during IESG review. 

Jari's has not said if this answers his concerns.

comments?

-gabriel

----- Forwarded Message ----
From: "[e-mail]" <[e-mail]>
To: [e-mail]; [e-mail]; Carsten Bormann <[e-mail]>; Schumacher Christian Peter Pii <[e-mail]>; [e-mail]
Sent: Sunday, March 18, 2007 1:18:51 PM
Subject: Your IETF LC comments on draft-ietf-6lowpan-format-11.txt

Thanks Jari for your comments.

Changes discussed below are in a version 12 under preparation but not yet 
submitted. 

> 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.

The document was written with this model in mind. Perhaps it can be made more
explicit.

For example, section 3 at the end talks about prefixes in plural:

   As usual, hosts learn IPv6 prefixes via router advertisements as per
   [I-D.ietf-ipv6-2461bis].  


As currently worded, perhaps there is an issue in that a given PAN ID seems
limited to only one prefix. A better wording is to have a given PAN ID map
to one link. 

Notice that the header compression scheme was done such that multiple prefixes
per link work fine: no particular prefix (other than link-local) is ever assumed.
Prefixes are sent in-line. And given that prefixes are learned via RAs (as usual),
there is no need for any additional text beyond that.

The suggested changes are:

OLD:
	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.

NEW:
	This document assumes that a PAN maps to a specific IPv6 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.

Done.

> > 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.

Well, in the absence of any mesh,
given that there is no actual link-layer multicast, even if the
mapping in Section 9 is done, the actual packets will travel over
broadcast, so there is no difference.

The only difference occurs in the mesh case. In this case, the actual
mechanism is fully defined by the mesh specification (separate document).
This document only defines that which must be common across all mesh
specifications (as there probably will be more than one): the address
mapping.

Suggested fix: this document should say that section 9 is only used if mesh
is in use. 

NEW:
	support for mapping of IPv6 multicast addresses MAY be provided

OLD:
	support for mapping of IPv6 multicast addresses MAY be provided
	in a mesh 


And add this line to the beginning of "Multicast Address Mapping":

	The functionality in this section MAY be
 applied only in a mesh-enabled LoWPAN.

> 
> > 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.

What is incorrect? This is the text in 2460 I looked at when writing the
above:

   A node must be able to accept a fragmented packet that, after
   reassembly, is as large as 1500 octets.  A node is permitted to
   accept fragmented packets that reassemble to more than 1500 octets.
   An upper-layer protocol or application that depends on IPv6
   fragmentation to send packets larger than the MTU of a path should
   not send packets larger than 1500 octets unless it has assurance that
   the destination is capable of reassembling packets of that larger
   size.

Our MTU is 1280. We must accept packets as large as 1500, but no more than that.
Reassembly of packets larger than that is optional in 2460, and we don't
do that, so we only need 11 bits. Or should we make it explicit that we don't
 support
PMTU discovery?

-gabriel

_______________________________________________
6lowpan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/6lowpan