Subject: [lp-wan] LP-WAN Scope question

From: Erik Nordmark <[email-masked]>
Date: Mon, 16 May 2016 12:44:04 -0700

I see the proposed charter discusses compression and 
fragmentation/segmentation, which are clearly critical for running IP on 
these technologies. Great work so far.

But before and during the BoF there was also some mentioning of routing 
(e.g., the vehicle convoy use case) which raised questions in my mind 
how IPv6 addresses/prefixes would be coordinated in such cases. I can't 
tell from the discussion whether such uses cases are being deferred to a 
later phase after the above issues have been taken care of. What is the 
intended scope?

Even in the case of a star topology there is a potential need for IPv6 
duplicate address detection (depending on how IPv6 addressing is done). 
Presumably the WG needs to consider this (even if it ends up leveraging 
work going on in 6LO), but there might be larger issues around 
bootstrapping where DAD is only one part of the bootstrapping sequence.
Is that something that you all see as part of the scope?

Regards,
    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 May 2016 09:02:24 +0000

Hello Erik;

I'm with you on both accounts;

- some LPWA Networking technology already have IPv6 (eg 802.15.4g, you can do 6LoWPAN, 6TiSCH). For those the first round of the WG would not apply, but further work may (should).

- It is highly probable in my mind that the devices will not form and register address. In the most constrained scenario, the remote IO use case, the device is an dongle attached wirelessly to the gateway, like a serial port on a PC, and it is not even aware of IP at all.  

- others, like LoRa or Sigfox, do not have IP support, but they have a unique identifier and security credentials. They may understand IP packetization, but the formats in the air will not reflect that.

We are looking at a model where the IP address is assigned by the gateway (GW), or by a controller (CTLR) that operates the gateway, as opposed of the device. You may call see that as a delegated form of autoconf (by GW) and DHCP (by CTLR). It is not clear yet if and how the device identifier interacts with the address formation.

One way to achieve delegated autoconf is as follows: the  GW would form a address for the device based on the device key (eg public) in a way similar to CGA, leveraging the unique ID in the hash. Like for CGA, there could be a few bits to add diversity in case of duplication, bits that could be signaled back to the device, so the device can infer its address from its key, ID, and those bits. 

Makes sense?

Pascal

Cheers,

Pascal

> -----Original Message-----
> From: lp-wan [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: lundi 16 mai 2016 21:44
> To: [email-masked]
> Subject: [lp-wan] LP-WAN Scope question
> 
> (e.g., the vehicle convoy use case) which raised questions in my mind how
> IPv6 addresses/prefixes would be coordinated in such cases. I can't tell from
> the discussion whether such uses cases are being deferred to a later phase
> after the above issues have been taken care of. What is the intended scope?
> 
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 May 2016 13:01:43 +0200

Le 17/05/2016 à 11:02, Pascal Thubert (pthubert) a écrit :
> - some LPWA Networking technology already have IPv6 (eg 802.15.4g,
> you can do 6LoWPAN, 6TiSCH). For those the first round of the WG
> would not apply, but further work may (should).
>
> - It is highly probable in my mind that the devices will not form and
> register address. In the most constrained scenario, the remote IO use
> case, the device is an dongle attached wirelessly to the gateway,
> like a serial port on a PC, and it is not even aware of IP at all.
>
> - others, like LoRa or Sigfox, do not have IP support, but they have
>  a unique identifier and security credentials.

What is the format of the unique identifier?

> They may understand IP packetization, but the formats in the air will
> not reflect that.
>
> We are looking at a model where the IP address is assigned by the
> gateway (GW), or by a controller (CTLR) that operates the gateway, as
> opposed of the device. You may call see that as a delegated form of
> autoconf (by GW) and DHCP (by CTLR). It is not clear yet if and how
> the device identifier interacts with the address formation.
>
> One way to achieve delegated autoconf is as follows: the  GW would
> form a address for the device based on the device key (eg public)

What is the format of the device key?

Alex

> in a way similar to CGA, leveraging the unique ID in the hash. Like
> for CGA, there could be a few bits to add diversity in case of
> duplication, bits that could be signaled back to the device, so the
> device can infer its address from its key, ID, and those bits.
>
> Makes sense?
>
> Pascal
>
>
> Cheers,
>
> Pascal
>
>> -----Original Message----- From: lp-wan
>> [mailto:[email-masked]] On Behalf Of Erik Nordmark Sent:
>> lundi 16 mai 2016 21:44 To: [email-masked] Subject: [lp-wan]
>> LP-WAN Scope question
>>
>> fragmentation/segmentation, which are clearly critical for running
>>  IP on these technologies. Great work so far.
>>
>> But before and during the BoF there was also some mentioning of
>> routing (e.g., the vehicle convoy use case) which raised questions
>>  in my mind how IPv6 addresses/prefixes would be coordinated in
>> such cases. I can't tell from the discussion whether such uses
>> cases are being deferred to a later phase after the above issues
>> have been taken care of. What is the intended scope?
>>
>> Even in the case of a star topology there is a potential need for
>> IPv6 duplicate address detection (depending on how IPv6 addressing
>>  is done). Presumably the WG needs to consider this (even if it
>> ends up leveraging work going on in 6LO), but there might be larger
>> issues around bootstrapping where DAD is only one part of the
>> bootstrapping sequence. Is that something that you all see as part
>> of the scope?
>>
>> Regards, Erik
>>
>> _______________________________________________ lp-wan mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/lp-wan
>
> _______________________________________________ lp-wan mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 17 May 2016 13:16:40 +0200

Hi Alex,

> Le 17 mai 2016 à 13:01, Alexandre Petrescu <[email-masked]> a écrit :
> 
> 
> 

This is technology specific. For LoRaWAN, you have a DevEUI, which IEEE EUI64. In other technologies, the devices are not following the IEEE format, but have assigned IDs in a centralized fashion. In all cases, there is a way to uniquely identify a device within a specific technology and quite often, this is following the IEEE EUI format.

Best,
Alexander

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 May 2016 13:50:13 +0200

Hi,

Le 17/05/2016 à 13:16, Alexander Pelov a écrit :
> Hi Alex,
>
>> Le 17 mai 2016 à 13:01, Alexandre Petrescu
>> <[email-masked] <mailto:[email-masked]>> a
>> écrit :
>>
>>
>>
> This is technology specific. For LoRaWAN, you have a DevEUI, which IEEE
> EUI64. In other technologies, the devices are not following the IEEE
> format, but have assigned IDs in a centralized fashion. In all cases,
> there is a way to uniquely identify a device within a specific
> technology and quite often, this is following the IEEE EUI format.

This is encouraging.  It would mean the device can form an address by 
appending that identifier to a prefix the router (controller?) would 
advertise.  That would be easy to specify and implement.

Alex

>>>> lundi 16 mai 2016 21:44 To: [email-masked] <mailto:[email-masked]>
>>>> Subject: [lp-wan]
>>>> LP-WAN Scope question
>>>>
>>>> list [email-masked] <mailto:[email-masked]>