Subject: Re: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 19 Mar 2016 02:20:27 +0000

Hello WG:

This document  in recent version made a couple of notable changes after LC version (03):
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-dect-ule-04

The authors have pointed to the main change in the document as:

Based on the experience from the latest implementation of the 6lo DECT-ULE for ULE Alliance, we have changed the method for deriving IID for link-local addresses. Now it is only allowed to derive IID for link-local from the DECT link layer identities. The MAC-48 address is now only an option for non-link-local, although not recommend because of privacy considerations.

I'd urge the WG to review the change in the document  and if you are okay with the change. 

Another major clarification  in 3.2.1: 

"A 6LN MUST NOT register more than one non-link-local addres on the   same prefix"

Question to the authors:  Please clarify what is meant by non-link-local address  ? Is it MAC address or derived IID?

Thanks,
-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 26, 2016 7:35 AM
To: [email-masked]
Cc: [email-masked]
Subject: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes of the IETF.

        Title           : Transmission of IPv6 Packets over DECT Ultra Low Energy
        Authors         : Peter B. Mariager
                          Jens Toftgaard Petersen
                          Zach Shelby
                          Marco van de Logt
                          Dominique Barthel
	Filename        : draft-ietf-6lo-dect-ule-04.txt
	Pages           : 19
	Date            : 2016-02-26

Abstract:
   DECT Ultra Low Energy is a low power air interface technology that is
   defined by the DECT Forum and specified by ETSI.

   The DECT air interface technology has been used world-wide in
   communication devices for more than 20 years, primarily carrying
   voice for cordless telephony but has also been deployed for data
   centric services.

   The DECT Ultra Low Energy is a recent addition to the DECT interface
   primarily intended for low-bandwidth, low-power applications such as
   sensor devices, smart meters, home automation etc.  As the DECT Ultra
   Low Energy interface inherits many of the capabilities from DECT, it
   benefits from long range, interference free operation, world wide
   reserved frequency band, low silicon prices and maturity.  There is
   an added value in the ability to communicate with IPv6 over DECT ULE
   such as for Internet of Things applications.

   This document describes how IPv6 is transported over DECT ULE using
   6LoWPAN techniques.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6lo-dect-ule/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-6lo-dect-ule-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-dect-ule-04

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Jens Toftgaard Petersen <[email-masked]>
Date: Sun, 20 Mar 2016 23:04:05 +0000

Hi Samita,

Answer to your question regarding "A 6LN MUST NOT register more than one non-link-local addres on the   same prefix"
What it means it that a 6LN most only register one address for each prefix. The IID can be derived from a MAC address (or DECT address), but preferably the IID is produced by other means for privacy reasons.

Best regards,
  Jens

-----Original Message-----
From: Samita Chakrabarti [mailto:[email-masked]] 
Sent: 19. marts 2016 03:20
To: Jens Toftgaard Petersen <[email-masked]>; Peter Mariager <[email-masked]>; [email-masked]; Zach Shelby ([email-masked]) <[email-masked]>; van de Logt, Marco <[email-masked]>
Cc: [email-masked]
Subject: RE: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

Hello WG:

Thanks,
-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 26, 2016 7:35 AM
To: [email-masked]
Cc: [email-masked]
Subject: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

Abstract:

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 21 Mar 2016 15:08:23 -0700

Sorry for the double post, but I'm adding my comments on 3.2.1 to this
thread
where they belong.

Delete the sentence that reads

Least significant bit of this address is the last bit
in network order.

In the sentence that reads

First bit is set to a one for addresses derived from
the RFPI and first bit is set to zero for addresses
derived from the IPEI.

You either want to substitute "i/g bit" or "8th bit" for "first" (two
places)

In the sentence that reads

>From these intermediate 48 bit addresses are derived
IIDs accordig to the guidance of [RFC4291].

s/accordig/according/

In the sentence that reads

In the derived IIDs the 7th bit is set to one to indicate
that the addresses are not global unique.

s/one/zero/  (See RFC 4941, Appendix A; note the u/l bit gets inverted in
the IID)
s/global/globally/

In the sentence that reads

For example from RFPI=11.22.33.44.55 the derived IID is
82:11:22:FF:FE:33:44:55 and from IPEI=01.23.45.67.89 the
derived IID is 02:01:23:FF:FE:45:67:89.

s/82/01/ and s/02/00/  (this is the net effect of the corrections made
above).

Regards, Kerry Lynn

On Sun, Mar 20, 2016 at 4:04 PM, Jens Toftgaard Petersen <[email-masked]> wrote:

> Hi Samita,
>
> Answer to your question regarding "A 6LN MUST NOT register more than one
> non-link-local addres on the   same prefix"
> What it means it that a 6LN most only register one address for each
> prefix. The IID can be derived from a MAC address (or DECT address), but
> preferably the IID is produced by other means for privacy reasons.
>
> Best regards,
>   Jens
>
> To: Jens Toftgaard Petersen <[email-masked]>; Peter Mariager <[email-masked]>;
> [email-masked]; Zach Shelby ([email-masked]) <
> [email-masked]>; van de Logt, Marco <[email-masked]>
> Cc: [email-masked]
> Based on the experience from the latest implementation of the 6lo DECT-ULE
> for ULE Alliance, we have changed the method for deriving IID for
> link-local addresses. Now it is only allowed to derive IID for link-local
> from the DECT link layer identities. The MAC-48 address is now only an
> option for non-link-local, although not recommend because of privacy
> considerations.
>
> Question to the authors:  Please clarify what is meant by non-link-local
> address  ? Is it MAC address or derived IID?
>
>
> Thanks,
> -Samita
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 31 Mar 2016 00:20:41 +0000

Hi Kerry,

Thank you for the comments.

Here are some observation comparing the  RFC4291 and the dect-ule 3.2.1 .

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kerry Lynn
Sent: Monday, March 21, 2016 3:08 PM
To: Jens Toftgaard Petersen; Peter Mariager; [email-masked]; Zach Shelby ([email-masked]); van de Logt, Marco; [email-masked]
Cc: Samita Chakrabarti
Subject: Re: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

Sorry for the double post, but I'm adding my comments on 3.2.1 to this thread
where they belong.

You either want to substitute "i/g bit" or "8th bit" for "first" (two places)

[SC>]  I think it means adding  a byte with “0” in front of 40-bit dect-ULE address and then make the most significant bit out of the 48-bit to 1 if it is derived from RFPI.  The word  “first bit” is confusing – instead most significant bit position in the newly formed 48-bit interface-address is more relevant.

s/accordig/according/

s/one/zero/  (See RFC 4941, Appendix A; note the u/l bit gets inverted in the IID)
[SC>] In the above explanation [ pre-pending x00], the 7th bit is always 0. So after inversion it becomes 1.

8bit +40-bit  IIDx ==> 0000 0000 :X:X:X:X:X
64-bit ==> 0000 0000:X:X:FF:FE:X:X:X
DECT-ULE-IID-1 format  -- 1000 0010:X:X:FF:FE:X:X:X (RFPI)
DECT-ULE-IID-2 format--   0000 0010:X:X:FF:FE:X:X:X (IPEI)

s/global/globally/

s/82/01/ and s/02/00/  (this is the net effect of the corrections made above).

[SC>]  With the above definition 82 or 02 in the left most byte of IID seems correct to me. Jens/co-authors please confirm.

Jens and co-authors: my recommendation (shepherd hat) would be to clarify the address formation in steps in the document.
Also, please use ‘ left most bit or right most bit’  as they apply.  And fix the typos as pointed out by Kerry.
Will you be able to publish the revised draft next week?

[SC>] Thanks,
-Samita

On Sun, Mar 20, 2016 at 4:04 PM, Jens Toftgaard Petersen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Samita,

Best regards,
  Jens

-----Original Message-----
From: Samita Chakrabarti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 19. marts 2016 03:20
To: Jens Toftgaard Petersen <[email-masked]<mailto:[email-masked]>>; Peter Mariager <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Zach Shelby ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; van de Logt, Marco <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

Hello WG:

Thanks,
-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, February 26, 2016 7:35 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 30 Mar 2016 21:04:25 -0400

On Wed, Mar 30, 2016 at 8:20 PM, Samita Chakrabarti <
[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Kerry
> Lynn
> *Sent:* Monday, March 21, 2016 3:08 PM
> *To:* Jens Toftgaard Petersen; Peter Mariager;
> [email-masked]; Zach Shelby ([email-masked]); van de
> Logt, Marco; [email-masked]
> *Cc:* Samita Chakrabarti
> *Subject:* Re: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt
>
>
>
> *[SC>]  I think it means adding  a byte with “0” in front of 40-bit
> dect-ULE address and then make the most significant bit out of the 48-bit
> to 1 if it is derived from RFPI.  The word  “first bit” is confusing –
> instead most significant bit position in the newly formed 48-bit
> interface-address is more relevant.*
>
>
Yes, I saw this interpretation was possible after I sent my response.  I
think the best
way to avoid confusion is to use the bit numbering shown in  RFC 4291,
Appendix A,
section "Links or Nodes with IEEE 802 48-bit MACs", in which case we'd be
talking
about bit 0.

> *[SC>] In the above explanation [ pre-pending x00], the 7th bit is always
> 0. So after inversion it becomes 1.*
>
>
>
RFC 4291, Appendix A very clearly says that IIDs derived from locally
assigned MACs
should have a zero in the u/l bit, whereas IIDs derived from globally
assigned MACs
should have a one in the u/l bit (bit 7).

For example, the u/l bit in a true IEEE EUI-64 will be zero to indicate it
is globally
unique.  The IID derived from this MAC would have bit 7 inverted to a value
of one.

Similarly, to properly generate an IEEE MAC-48 from the 40-bit DECT address,
we should have set the u/l bit to one to indicate it was locally assigned.
The IID
derived from this MAC would have bit 7 inverted to a value of zero.

To avoid confusion, the authors might want to consider the guidance under
RFC 4291,
Appendix A, section "Links with Other Kinds of Identifiers".  Of course,
bit 7 would
still be zero in the derived IID.

*8bit +40-bit  IIDx **è** 0000 0000 :X:X:X:X:X*
>
> *64-bit **è** 0000 0000:X:X:FF:FE:X:X:X*
>
> *DECT-ULE-IID-1 format  -- 1000 0010:X:X:FF:FE:X:X:X (RFPI)*
>
> *DECT-ULE-IID-2 format--   0000 0010:X:X:FF:FE:X:X:X (IPEI)*
>
>
>
The end result is now

DECT-ULE-IID-1 format -- 1000 0000:X:X:FF:FE:X:X:X (RFPI)
DECT-ULE-IID-2 format -- 0000 0000:X:X:FF:FE:X:X:X (IPEI)

> *[SC>]  With the above definition 82 or 02 in the left most byte of IID
> seems correct to me. Jens/co-authors please confirm.*
>
>
>
I maintain it should be s/82/80 and s/02/00.  They could leave it as is,
but then
they really aren't following the guidance of RFC 4291.

Kerry

> Jens and co-authors: my recommendation (shepherd hat) would be to clarify
> the address formation in steps in the document.
>
> *[SC>] Thanks,*
> *-Samita*

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 31 Mar 2016 07:43:30 +0000

Hi Kerry,

I don’t have the IPv6 IID conversion code available right away, but I checked again in two places:

RFC 4291 Appendix says, u=0 when it is in 48-bit MAC address form.
But u=1 , when it is in interface identifier form.

An example is the 48-bit IEEE MAC with
   Global scope:

   |0                           1|1                                           3|3                                                            4|
 |0                            5|6                                           1|2                                                           7|
   +-------------------+-----------------------------+--------------------------------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+

where "c" is the bits of the assigned company_id, "0" is the value of
   the universal/local bit to indicate Global scope, "g" is
   individual/group bit, and "m" is the bits of the manufacturer-
   selected extension identifier.  The interface identifier would be of
   the form:

   |0                            1|1                               3|3                                            4|4                                                          6|
   |0                           5|6                                1|2                                           7|8                                                           3|
   +--------------------+--------------------+-------------------------------+-------------------------------------+
   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   When IEEE 802 48-bit MAC addresses are available (on an interface or
   a node), an implementation may use them to create interface
   identifiers due to their availability and uniqueness properties

And here is another diagram with clarity :
https://technet.microsoft.com/en-us/library/cc736439(v=ws.10).aspx

Thanks,
-Samita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kerry Lynn
Sent: Wednesday, March 30, 2016 6:04 PM
To: Samita Chakrabarti
Cc: Jens Toftgaard Petersen; Peter Mariager; [email-masked]; Zach Shelby ([email-masked]); van de Logt, Marco; [email-masked]
Subject: Re: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

On Wed, Mar 30, 2016 at 8:20 PM, Samita Chakrabarti <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kerry,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kerry Lynn
Sent: Monday, March 21, 2016 3:08 PM
To: Jens Toftgaard Petersen; Peter Mariager; [email-masked]<mailto:[email-masked]>; Zach Shelby ([email-masked]<mailto:[email-masked]>); van de Logt, Marco; [email-masked]<mailto:[email-masked]>
Cc: Samita Chakrabarti
Subject: Re: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

Yes, I saw this interpretation was possible after I sent my response.  I think the best
way to avoid confusion is to use the bit numbering shown in  RFC 4291, Appendix A,
section "Links or Nodes with IEEE 802 48-bit MACs", in which case we'd be talking
about bit 0.

s/accordig/according/

RFC 4291, Appendix A very clearly says that IIDs derived from locally assigned MACs
should have a zero in the u/l bit, whereas IIDs derived from globally assigned MACs
should have a one in the u/l bit (bit 7).

For example, the u/l bit in a true IEEE EUI-64 will be zero to indicate it is globally
unique.  The IID derived from this MAC would have bit 7 inverted to a value of one.

Similarly, to properly generate an IEEE MAC-48 from the 40-bit DECT address,
we should have set the u/l bit to one to indicate it was locally assigned.  The IID
derived from this MAC would have bit 7 inverted to a value of zero.

To avoid confusion, the authors might want to consider the guidance under RFC 4291,
Appendix A, section "Links with Other Kinds of Identifiers".  Of course, bit 7 would
still be zero in the derived IID.

The end result is now

s/global/globally/

I maintain it should be s/82/80 and s/02/00.  They could leave it as is, but then
they really aren't following the guidance of RFC 4291.

Kerry

[SC>] Thanks,
-Samita

Best regards,
  Jens

-----Original Message-----
From: Samita Chakrabarti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 19. marts 2016 03:20
To: Jens Toftgaard Petersen <[email-masked]<mailto:[email-masked]>>; Peter Mariager <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Zach Shelby ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; van de Logt, Marco <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

Hello WG:

Thanks,
-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, February 26, 2016 7:35 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [6lo] I-D Action: draft-ietf-6lo-dect-ule-04.txt

Abstract:

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 31 Mar 2016 08:18:46 -0400

On Thu, Mar 31, 2016 at 3:43 AM, Samita Chakrabarti <
[email-masked]> wrote:

>    |0                           1|1
>                                 3|3
>                                                4|
>  |0                            5|6
>                               1|2
>                                                    7|
>    |0                            1|1
>                    3|3
>                                 4|4
>                                                 6|
>    |0                           5|6
>                     1|2
>                               7|8
>                                                    3|
Hi Samita,

My point is that the starting point is NOT a 48-bit IEEE MAC with global
scope,
but a 48-bit MAC with local scope.  It doesn't contain a company ID in the
high
order bits the way a universally administered 48-bit IEEE MAC would, but is
formed instead from padding appended to an identifier from a different name-
space.  This is analogous to IIDs formed from short identifiers in RFC 4944;
section 6 states "...in the resultant interface identifier, the
Universal/Local (U/L)
bit SHALL be set to zero in keeping with the fact that this is not a
globally
unique value."

Now it may be that 40-bit DECT addresses *are* unique, but that doesn't mean
that a 48-bit IEEE MAC formed from the DECT address will be.  In any case,
I suggest you ask Brian Carpenter for a second opinion.

Regards, Kerry

> *Sent:* Wednesday, March 30, 2016 6:04 PM
> *To:* Samita Chakrabarti
> *Cc:* Jens Toftgaard Petersen; Peter Mariager;