Subject: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-09

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Aug 2010 17:44:53 +0200

LoWPANners,

the HC-08 WGLC has closed a while ago and brought us very solid consensus that
this is the way forward, but also a couple of small issues in the periphery.

Jonathan has submitted HC-09 to handle the WGLC comments to HC-08.
There are only some small changes, which could be considered clarifications, 
but they are technical in nature and it is probably worthwhile to get some 
final WG review for these small changes.  Given the amount of implementation
experience we now have, I don't expect this will be a repeat event.

So, this is now a Working-Group Last-Call for:

http://tools.ietf.org/html/draft-ietf-6lowpan-hc-09

The document is intended to be submitted by this Working Group to the
IESG for publication as a Standards-Track Document.

This is a one-week Working-Group Last-Call, ending on 2010-08-30
(Monday, August 30, 2010) at 2359 UTC.

Please review the changes to the document carefully, and send your
comments to the 6lowpan list.  A convenient view of the changes is at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-6lowpan-hc-09.txt

Carsten

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 24 Aug 2010 11:24:30 -0700

HC-09 looks in good shape.

However, I have one suggestion and one question. I hate to bring them
up at such a late stage, but I only realized them today while reading
through HC-09.

Could the stateless address compression be changed slightly to be more
inline with how IIDs are derived from 16bit MAC addresses. Something
like the following:

SAM: Source Address Mode:
If SAC=0:
00: 128 bits. The full address is carried in-line.
01: 64 bits. The first 64-bits of the address are elided.
The value of those bits is the link-local prefix padded with
zeros. The remaining 64 bits are carried in-line.
10: 16 bits. The first 112 bits of the address are elided.
The value of the first 64 those bits is the link-local prefix
padded with zeros. The following 48 bits are the first 48 bits
of the IID as defined in section 3.2.2. The remaining 16 bits
are carried in-line.

DAM: Destination Address Mode:
If M=0 and DAC=0 This case matches SAC=0 but for the destination
address:
00: 128 bits. The full address is carried in-line.
01: 64 bits. The first 64-bits of the address are elided.
The value of those bits is the link-local prefix padded with
zeros. The remaining 64 bits are carried in-line.
10: 16 bits. The first 112 bits of the address are elided.
The value of the first 64 those bits is the link-local prefix
padded with zeros. The following 48 bits are the first 48 bits
of the IID as defined in section 3.2.2. The remaining 16 bits
are carried in-line.

Without this change, I see it highly unlikely that 112 bit stateless
address compression will ever be used, because the 0000:00FF:FE00:XXXX
IID pattern could only ever be elided in 128 bit stateless compression
mode.

This also raises a question for stateful compression mode: What must an
decoder do when it has a context entry with a prefix length less than
what is provided in the Address Mode field (SAM or DAM). Effectively,
an undefined gap in the decoded IP address exists.  For example:

SAC = 1 and SAM = b10 (16 bits inline)
Context Entry = 2001:AAAA:BBBB:CCCC::/64
Inline portion of source address = 1234

So would the decoded IP address become [#1]:

2001:AAAA:BBBB:CCCC:0000:0000:0000:1234

or [#2]:

2001:AAAA:BBBB:CCCC:0000:00FF:FE00:1234

or [#3] should the decoder discard the packet.

Similarly, is an encoder allowed to send a packet with the SAM or DAM
fields set in such a way to create a gap between context prefix length
and inline address bits?

Regards

Dario

Carsten Bormann wrote:

LoWPANners,

Carsten

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

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 24 Aug 2010 11:38:36 -0700

On Aug 24, 2010, at 11:24 AM, Dario Tedeschi wrote:

> Could the stateless address compression be changed slightly to be more inline with how IIDs are derived from 16bit MAC addresses. Something like the following:
>             The value of 
> the first 64 those
>  bits is the link-local prefix
>             padded with zeros. 
> The following 48 bits are the first 48 bits
>             The value of 
> the first 64 those
>  bits is the link-local prefix
>             padded with zeros. 
> The following 48 bits are the first 48 bits

Good catch.  This text was left over from when we were debating what value to use for those 48-bits.  Now that it's 0000:00ff:fe00:xxxx, we should update the text to reflect that.    It's a straightforward edit.  I defer to the chairs on the best process of making the change.

> Without this change, I see it highly unlikely that 112 bit stateless address compression will ever be used, because the 0000:00FF:FE00:XXXX IID pattern could only ever be elided in 128 bit stateless compression mode.
> 
> This also raises a question for stateful compression mode: What must an decoder do when it has a context entry with a prefix length less than what is provided in the Address Mode field (SAM or DAM). Effectively, an undefined gap in the decoded IP address exists.  For example:

Section 3.2.2 states:

 This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is
 also used to reconstruct any part of an IID not covered by context
 information when only 16 bits are carried in-line (SAC/DAC=10).

> Similarly, is an encoder allowed to send a packet with the SAM or DAM fields set in such a way to create a gap between context prefix length and inline address bits?

One view is to make it a context information problem - if the context doesn't say what to do with a gap, then the compressor is not allowed to and the decompressor should treat it as an error.

--
Jonathan Hui

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 24 Aug 2010 12:33:49 -0700

Thanks for clarification.