Subject: [6lowpan] comments and questions on rfc4944

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 12:44:06 +0100

Dear 6LoWPANers,

I have some comments and questions on RFC4944.  I wrote these comments 
while reading the RFC to get familiar with it.  I don't know what are 
the intentions of progressing the draft.  For the record.

> IEEE 802.15.4 defines four types of frames: beacon frames, MAC 
> command frames, acknowledgement frames, and data frames.  IPv6 
> packets MUST be carried on data frames.  Data frames may optionally 
> request that they be acknowledged.  In keeping with [RFC3819], it is 
> recommended that IPv6 packets be carried in frames for which 
> acknowledgements are requested so as to aid link-layer recovery.

So IPv6 packets must be carried on data frames, and on frames for which 
acks are requested.  Are all data frames requesting acks?  If not, what 
distinguishes data frames requesting acks from data frames not 
requesting acks?

>    2.  A short destination address is included in the frame, and it MUST
>        match the broadcast address (0xffff).

What is the IP destination address in this case?

>   2.  Even though the above space calculation shows the worst-case
>        scenario, it does point out the fact that header compression is
>        compelling to the point of almost being unavoidable.  Since we
>        expect that most (if not all) applications of IP over IEEE
>        802.15.4 will make use of header compression, it is defined below
>        in Section 10.

This is dangerously approaching saying IP HC is a MUST for 15.4 
networks.  I disagree.

> 5. LoWPAN Adaptation Layer and Frame Format

Is this mandatory use in 15.4 IPv6 networks?

>         | 01  000001 | IPv6       - Uncompressed IPv6 Addresses      |

or Uncompressed IPv6 headers (the full IPv6 headers are present)?

because later it says:
>    IPv6:  Specifies that the following header is an uncompressed IPv6
>       header [RFC2460].

> 6. Stateless Address Autoconfiguration
> 
> 
>    This section defines how to obtain an IPv6 interface identifier.

So why is the section title misleading.

>    The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may
>    be based on the EUI-64 identifier [EUI64] assigned to the IEEE
>    802.15.4 device.  In this case, the Interface Identifier is formed
>    from the EUI-64 according to the "IPv6 over Ethernet" specification
>    [RFC2464].

Is there an 802.3 layer on top of 802.15.4?  This is good to clarify.

>    An IPv6 address prefix used for stateless autoconfiguration [RFC4862]
>    of an IEEE 802.15.4 interface MUST have a length of 64 bits.

Does this effectively forbid 54bit prefix lengths?

>    The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface
>    is formed by appending the Interface Identifier, as defined above, to
>    the prefix FE80::/64.

/64 or /10? (rfc3513.txt says   Link-local unicast   1111111010 
   FE80::/10       2.5.6)

 > 9. Multicast Address Mapping
 >
>    The functionality in this section MUST only be used in a mesh-enabled
>    LoWPAN.

Yes, but it's not clear: will a mesh-enabled LoWPAN use route-over or 
mesh-under routing?

>    The functionality in this section MUST only be used in a mesh-enabled
>    LoWPAN.  An IPv6 packet with a multicast destination address (DST),
>    consisting of the sixteen octets DST[1] through DST[16], is
>    transmitted to the following 802.15.4 16-bit multicast address:

But I thought 802.15.4 wihtout adaptation layer doesn't have multicast 
addresses.

What happens with the lost octet of a solicited-node IP multicast 
address? (it has 3, and this uses only 2).

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

Yes, ROHC evolved...

> 10.1. Encoding of IPv6 Header Fields
> 
> 
>    By virtue of having joined the same 6LoWPAN network, devices share
>    some state.  This makes it possible to compress headers without
>    explicitly building any compression context state.  Therefore,
>    6LoWPAN header compression does not keep any flow state; instead, it
>    relies on information pertaining to the entire link.  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: Version is IPv6; both IPv6 source and destination
>    addresses are link local;

For this reason, 6LoWPAN HC may not be useful when the network is 
connected to the Internet (src/dst addresses be global).

> both the
>    Traffic Class and the Flow Label are zero;

So no qos and HC, ok?

> and the Next Header is
>    UDP, ICMP or TCP.

So no Mobile IPv6 and HC, ok?

Alex

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 18 Feb 2009 07:53:59 -0800

Hi Alex, as you have noticed, RFC 4944 needs cleanup. We have already  
discussed updating and/or replacing RFC 4944 within this WG.

Please see additional comments inline:

On Feb 18, 2009, at 3:44 AM, Alexandru Petrescu wrote:
> Dear 6LoWPANers,
>
> I have some comments and questions on RFC4944.  I wrote these  
> comments while reading the RFC to get familiar with it.  I don't  
> know what are the intentions of progressing the draft.  For the  
> record.
>
>> request that they be acknowledged.  In keeping with [RFC3819], it  
>> is recommended that IPv6 packets be carried in frames for which  
> So IPv6 packets must be carried on data frames, and on frames for  
> which acks are requested.  Are all data frames requesting acks?  If  
> not, what distinguishes data frames requesting acks from data frames  
> not requesting acks?

There is an ack request bit in the 15.4 header. Please see the  
referenced 15.4 spec.

> What is the IP destination address in this case?

A multicast address.

> This is dangerously approaching saying IP HC is a MUST for 15.4  

You are correct. That's why RFC 4944 also specifies uncompressed IPv6  
headers.

> Is this mandatory use in 15.4 IPv6 networks?

Yes. The adaptation layer also adds a protocol dispatch that is sorely  
missing from the 15.4 header.

>>   IPv6:  Specifies that the following header is an uncompressed IPv6

Yes. Should be "Uncompressed IPv6 Header".

> So why is the section title misleading.

Not sure what you mean. One has to construct an IID somehow and this  
section specifies how to obtain one from a 15.4 address.

> Is there an 802.3 layer on top of 802.15.4?  This is good to clarify.

No. But you're right, the analogy is not a good one. 802.2. has 6-byte  
addrs, while 15.4 has 8-byte EUI-64's.

> Does this effectively forbid 54bit prefix lengths?

You're right. It should say something closer to what's in RFC 4862.  
Specifically:

    1.  The left-most 'prefix length' bits of the address are those of
        the link-local prefix.

    2.  The bits in the address to the right of the link-local prefix  
are
        set to all zeroes.

    3.  If the length of the interface identifier is N bits, the right-
        most N bits of the address are replaced by the interface
        identifier.

(Remove link-local to support arbitrary prefixes).

> /64 or /10? (rfc3513.txt says   Link-local unicast   1111111010    

Should be /10 with zeros padded as mentioned above.

> Yes, but it's not clear: will a mesh-enabled LoWPAN use route-over  
> or mesh-under routing?

There is still debate within the 6LoWPAN group on this subject.

> But I thought 802.15.4 wihtout adaptation layer doesn't have  
> multicast addresses.

When not using a mesh addressing header, MAC-layer broadcast is used  
to support multicast.

> address? (it has 3, and this uses only 2).

When using mesh addressing header, you only have the last 13 bits to  
work with. Think of these bits as a possible optimization so that the  
adaptation layer can optimize multicast delivery over multiple hops.  
BTW, I don't believe we should be specifying L2-stuff like this within  
the IETF. Much of the stuff in the RFC was there long before I got my  
hands on it.

>>   There is much published and in-progress standardization work on

And is still flow-based...

> connected to the Internet (src/dst addresses be global).

Exactly right. Which is why we're actively working on a new HC  
specification.

>>   Traffic Class and the Flow Label are zero;

Fixed in the new HC.

> So no Mobile IPv6 and HC, ok?

Fixed in the new HC.

--
Jonathan Hui

>
>
> Alex
>
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 17:47:12 +0100

Hi Jonathan,

Jonathan Hui a écrit :
>>> packets MUST be carried on data frames.  Data frames may
>>> optionally request that they be acknowledged.  In keeping with
>>> [RFC3819], it is recommended that IPv6 packets be carried in
>>> frames for which acknowledgements are requested so as to aid
>>> link-layer recovery.
>> 
>>  not, what distinguishes data frames requesting acks from data
>> frames not requesting acks?
> 

Ok, I see, it would have been clearer if it said "be carried in data
frames for which..." instead of "be carried in frames for which...".
BEcause otherwise makes think the "data frames" are different than the
"frames requesting acks".

>>> 2.  A short destination address is included in the frame, and it
>>> MUST match the broadcast address (0xffff).
>> 

Which IP multicast address?  The all-nodes multicast address?  The
all-routers multicast address?    Which scope (interface, link, site)?
A newly defined 'all-somethings' address? (rfc3513 lists some
possibilities).

> Yes. The adaptation layer also adds a protocol dispatch that is
> sorely missing from the 15.4 header.

I think link-layer multicast capabilities are more missing than anything
else.  More important than HC too and than mesh-under routing.

>>> 6. Stateless Address Autoconfiguration This section defines how
>>> to obtain an IPv6 interface identifier.
>> 

95% of text in this section describes how to form the IID.  I think it
would be better called "Forming an IID on 802.15.4" rather than
Stateless Address Autoconfiguration.

(the fact that rfc2464 calls its section 4 "Stateless Autoconfiguration"
  is a misnomer which should be corrected, because (1) makes people think
it's about an address being autoconfigured statelessly - it's actually
an IID not an address, and (2) it can easily be misunderstood for
"Stateless Address Autoconfiguration" RFC4862 which is much more than
just forming an IID and involves messages being exchanged.)

>>> An IPv6 address prefix used for stateless autoconfiguration
>>> [RFC4862] of an IEEE 802.15.4 interface MUST have a length of 64
>>> bits.
>> 
> 2.  The bits in the address to the right of the link-local prefix are
>  set to all zeroes.
> 
> most N bits of the address are replaced by the interface identifier.

I fully agree with this 3rd point.  An implementation does so.

I think this may be used to suggest correction to RFC2464 as well (it
requires the prefix to be 64bits, bottom of page 3, and I disagree, it
could be shorter).  I think I will post separately see what people think
on the 6man list.

[...]
>  work with. Think of these bits as a possible optimization so that
> the adaptation layer can optimize multicast delivery over multiple
> hops. BTW, I don't believe we should be specifying L2-stuff like this
> within the IETF.

This is what I'm thinking too.

But I don't know how to make it otherwise work.  If IEEE doesn't offer a
multicast-capable link-layer, and if nobody else does, I'm afraid many
IPv6-based protocols simply won't work.

I think it could be too much work to modify every other protocol
(DHCPv6, Mobile IPv6, ND, SLAAC, OSPF, RIPng to name a few relying on
link-layer multicast) to work on such specific link-layer.

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

Sounds as an inconvenient of it, but I don't see 'flow' mentioned in HC
(for other than Flow Label).  I would have expected to see how HC is not
flow-based, or similar.

Also, I would have expected to see the MANET Packet Format, rfc5444,
ways of compressing IP addresses and prefixees.

>>> 10.1. Encoding of IPv6 Header Fields By virtue of having joined
>>> the same 6LoWPAN network, devices share some state.  This makes
>>> it possible to compress headers without explicitly building any
>>> compression context state.  Therefore, 6LoWPAN header compression
>>> does not keep any flow state; instead, it relies on information
>>> pertaining to the entire link.  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:
>>> Version is IPv6; both IPv6 source and destination addresses are
>>> link local;
>> 

Oh I see, the HC draft, ok.

Alex