Subject: [Int-dir] Request for review from LLN experts

From: Ted Lemon <[email-masked]>
Date: Thu, 29 May 2014 05:34:28 -0400

I know there are several people on the internet area directorate who are knowledgable about LLNs.   Can you take a look at this message and respond particularly to question 1?   You can respond to me rather than to the list if you prefer not to get involved in the ensuing flame war.

Thanks!

Begin forwarded message:

> From: "Liubing (Leo)" <[email-masked]>
> Subject: [v6ops] ULA #3 NPTv6 Use Case
> Date: May 29, 2014 at 4:28:50 AM GMT-4
> To: v6ops WG <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> Hi, All
> 
> We're going to update the ULA draft. Before making a new version, I think it would be helpful to confirm/discuss several important topics which were discussed in last IETF meeting. 
> 
> I'd like to discuss the topics in different mail threads respectively.
> (Current draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02)
> ******************************************************************************
> 
> #3 NPTv6 Use Case
> 
> In current draft Section 3.2.1, there is an NPTv6 use case:
>  "In some very constrained situations(for example, in the sensors), the
>   network needs ULA as the on-demand and stable addressing which
>   doesn't need much code to support address assignment mechanisms like
>   DHCP or full ND (Note: surely it needs SLAAC). If the network also
>   needs to connect to the outside, then there can be an NPTv6 gateway
>   which is not subject to extreme resource constraints. Especially when
>   a lightweight isolated network needs to add Internet connectivity,
>   this is quite a straightforward and efficient way."
> 
> This use case is not based on real experience, but an assumption that supporting multiple prefixes might be a heavy burden for some resource-constrained nodes such as sensors. Because it needs to store multiple addresses and dealing with the address selection problem.
> 
> Question 1:
> In last IETF meeting, Lorenzo questioned this assumption whether it is reasonable. I'd like to hear opinions from you on this issue. If it's unreasonable, we'll move the use case out of the draft.
> 
> Question 2:
> Besides the resource-constrained use case. There is another case which was raised by Alex and has been talked a lot in 6man two months ago: one node is assigned a /64, and it is the gateway of multi-subnets. This might probably happen in the 3GPP terminals. 3GPP R11 supports DHCP-PD, but former specifications only support /64. Current networks just haven't implemented R11. 
> Besides DHCP-PD, another solution for the multi-subnets is bridging them at L2. But it is not feasible in some situations. For example, In a vehicle there might be numerous incompatible L2s.
> 
> I think it is a reasonable use case to be documented.
> 
> Question 3:
> This question is derived from Question 2. Current draft only refers NPTv6, but might been other IPv6 NAT implementations available in the vehicle/IoT networks. Shall we expand the "ULA+NPTv6" case to a generic "ULA+IPv6 NAT" ?  (Note: NPTv6 is the only standardized IPv6 NAT mechanism so far) .
> 
> Regards,
> Bing
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ralph Droms <[email-masked]>
Date: Thu, 29 May 2014 09:02:57 -0400

Off the top of my head reaction.

On May 29, 2014, at 5:34 AM 5/29/14, Ted Lemon <[email-masked]> wrote:

>> DHCP or full ND (Note: surely it needs SLAAC).

I honestly don't see the relationship between ULA and DHCP/full ND.  Use of a ULA *might* avoid "re-prefixing" (a subset of renumbering), but is, as far as I can tell, orthogonal to the assignment of addresses *within* a ULA or global prefix.

I think what they really mean is "re-prefixing", which the use of a ULA can avoid.

>> If the network also

I don't know of any real-world specifications (my in-depth experience is in ZigBee-IP and Wi-SUN FAN) that specify the use of ULAs to avoid the stack complexity of dealing with multiple prefixes.   If I recall correctly (and the Wi-SUN FAN spec is still under development), those specs support the use of ULAs for disconnected operation and security through address isolation but not in combination with NPTv6 for simplicity.  Having worked through parts an implementation for a constrained device, multiple prefixes don't seem to be a major source of complexity.  That is, the stack certainly needs extra code and data space to deal with multiple prefixes.  However, that extra complexity is dwarfed by, say, RPL.

>> I think it is a reasonable use case to be documented.

Is this scenario correct?  Is there a version of 3GPP that assigns a single /64, perhaps shared by the upstream link and anything downstream of the 3GPP device?  I think the scenario needs to be checked for correctness.

In any event, I could imagine use of a ULA downstream from the hypothetical device that has a single /64 for local networks.  I don't know if that use case is officially specified anywhere.

>> This question is derived from Question 2. Current draft only refers NPTv6, but might been other IPv6 NAT implementations available in the vehicle/IoT networks. Shall we expand the "ULA+NPTv6" case…

No.  Under no circumstances should the IETF document anything regarding IPv6 NAT, beyond NPTv6.

- Ralph

> Int-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-dir

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 May 2014 09:13:45 -0400

> I don't know of any real-world specifications (my in-depth experience is in ZigBee-IP and Wi-SUN FAN) that specify the use of ULAs to avoid the stack complexity of dealing with multiple prefixes.…

OK, thanks.   This is very helpful.

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 29 May 2014 21:37:15 +0300

>>> Question 2:
>>> Besides the resource-constrained use case. There is another case which was raised by Alex
>>> and has been talked a lot in 6man two months ago: one node is assigned a /64, and it is the
>>> gateway of multi-subnets. This might probably happen in the 3GPP terminals. 3GPP R11 supports
>>> DHCP-PD, but former specifications only support /64. Current networks just haven't implemented
>>> R11. Besides DHCP-PD, another solution for the multi-subnets is bridging them at L2. But it
>>> is not feasible in some situations. For example, In a vehicle there might be numerous
>>> incompatible L2s.
>>>
> Is this scenario correct?  Is there a version of 3GPP that assigns a single /64, perhaps
 > shared by the upstream link and anything downstream of the 3GPP 
device?  I think the scenario
 > needs to be checked for correctness.

All releases of 3GPP assign a single /64 to the mobile handlset (per PDN 
Connection - theoretically a device may have max 11 /64s assigned this 
way). The sharing of that same prefix to downstream LAN(s) is _not_ in 
any spec but definitely doable as an implementation hack in the mobile 
handset without breaking things.

There is actually a draft that sidetracks this: draft-ietf-v6ops-64share-10

DHCPv6-PD is, btw, rel-10 feature, not rel-11.

- Jouni

---

From: Ralph Droms <[email-masked]>
Date: Thu, 29 May 2014 15:11:49 -0400

On May 29, 2014, at 2:37 PM 5/29/14, Jouni Korhonen <[email-masked]> wrote:

> > shared by the upstream link and anything downstream of the 3GPP device?  I think the scenario
> All releases of 3GPP assign a single /64 to the mobile handlset (per PDN Connection - theoretically a device may have max 11 /64s assigned this way). The sharing of that same prefix to downstream LAN(s) is _not_ in any spec but definitely doable as an implementation hack in the mobile handset without breaking things.
> 

OK, thanks.

And, to be clear, looking ahead to question 3 ... subnetted ULA+NPTv6 does *not* apply in the 3GPP-/64 case, right?  NPTv6 doesn't allow multiple ULA /64s to be mapped into a single GUA /64?

- Ralph

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 29 May 2014 23:05:59 +0300

5/29/2014 10:11 PM, Ralph Droms kirjoitti:
> And, to be clear, looking ahead to question 3 ... subnetted ULA+NPTv6 does *not*
 > apply in the 3GPP-/64 case, right?  NPTv6 doesn't allow multiple ULA 
/64s to be
 > mapped into a single GUA /64?

Correct.

- Jouni

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 May 2014 08:39:00 +0000

Hi Ted and all:

> > This use case is not based on real experience, but an assumption that
> supporting multiple prefixes might be a heavy burden for some resource-
> constrained nodes such as sensors. Because it needs to store multiple
> addresses and dealing with the address selection problem.
> >
> > Question 1:
> > In last IETF meeting, Lorenzo questioned this assumption whether it is
> reasonable. I'd like to hear opinions from you on this issue. If it's
> unreasonable, we'll move the use case out of the draft.

[PT] In the IPv6 LLN standard work that I am most familiar with (ISA100.11a, IEC 62734, 6TiSCH), there is no specific recommendation of using ULA. In fact, ISA100 does not enforce that the IPv6 address is a valid IPv6 address.

There prefix that the device use in a 6LoWPAN network is somewhat abstract in that they do not show up in the compressed packet but in some hash somewhere.
It is passed in the RA and could be easily refreshed in that it only impacts the piece that computes the pseudo headers.

e.g. IEC 62734 extends the concept of UDP checksum (which can compressed in 6LoWPAN) for its Message Integrity Check and that includes the UDP pseudo header.
In other words there was some proposal in the past (I think that was Laurent Toutain) that suggested that the prefix is actually decided by the border router for packets leaving the LLN.

OTOH the lack of a good identity system lead to the widespread use of the IPv6 address of the device as app level identifier for the device. This makes renumbering quite cumbersome. So the need for stable addressing in existing standards is certain. Unsure what on-demand means here but as we extend the current (fully managed) Industrial LLN operations to more a autonomic behaviour (RPL, draft-pritikin-)  addressing will have to be fully automated. 
 
> >
> > Question 2:
> > Besides the resource-constrained use case. There is another case which
> was raised by Alex and has been talked a lot in 6man two months ago: one
> node is assigned a /64, and it is the gateway of multi-subnets. This might
> probably happen in the 3GPP terminals. 3GPP R11 supports DHCP-PD, but
> former specifications only support /64. Current networks just haven't
> implemented R11.
> > Besides DHCP-PD, another solution for the multi-subnets is bridging them
> at L2. But it is not feasible in some situations. For example, In a vehicle there
> might be numerous incompatible L2s.
> >

[PT] This might be related Network Address Protection / multihoming cases which uses MIP or LISP inside the private network as opposed to outside:
1) a ULA only network  is deployed inside the network 
2) each border router owns a /64 and acts as MIP HA
3) a device that need to reach the outside or be reachable via a border router obtains a Home Address from that BR
4) the device uses its ULA-based address as careof address and a MIP tunnel is used inside the multihomed network to the BR / HA 
5) In case of a loss of an ISP, the MIP tunnels dies and the nodes register to an alternate, thus obtaining transport through the alt ISP
Note that I know of some IPR about this technique.

> > Question 3:
> > This question is derived from Question 2. Current draft only refers NPTv6,
> but might been other IPv6 NAT implementations available in the vehicle/IoT
> networks. Shall we expand the "ULA+NPTv6" case to a generic "ULA+IPv6
> NAT" ?  (Note: NPTv6 is the only standardized IPv6 NAT mechanism so far) .
> >
[PT] Looks like a bad idea for reason of scale.  Note that more often than not there will be a local termination of the transport for data massaging, so the communication to the outside (SCADA...) usually does not rely on the device's IPv6 address. 

All in all, ULA is certainly very suitable in an LLN and a ML subnet that federates a number of such.

Cheers,

Pascal

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 May 2014 11:49:50 +0100

> All in all, ULA is certainly very suitable in an LLN and a ML subnet that federates a number of such.

Thanks--your perspective on this was quite a bit different from the others, and therefore particularly helpful.   You didn't really speak to the multiple address issue--does it make sense for a 6lowpan node to have multiple addresses, or is the expectation that the gateway between the 6lowpan network and the rest of the world will be doing translation anyway, and hence it can deal with that complexity?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 May 2014 13:45:01 +0000

In the discussions I had earlier, Ted, it was not expected that the device would have multiple addresses nor would renew them anytime soon...
And yes, the idea that the gateway would take care of issues is appealing.

Cheers,

Pascal

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: vendredi 30 mai 2014 12:50
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]
> Subject: Re: [Int-dir] Request for review from LLN experts
> 
> Thanks--your perspective on this was quite a bit different from the others,
> and therefore particularly helpful.   You didn't really speak to the multiple
> address issue--does it make sense for a 6lowpan node to have multiple
> addresses, or is the expectation that the gateway between the 6lowpan
> network and the rest of the world will be doing translation anyway, and
> hence it can deal with that complexity?

---

From: Ralph Droms <[email-masked]>
Date: Fri, 30 May 2014 09:50:20 -0400

> And yes, the idea that the gateway would take care of issues is appealing.

Pascal - do you know of any specific protocols or specifications where this behavior (in which the gateway uses NPTv6 to translate between a ULA prefix in the LLN and an external GUA) is explicitly defined or required today?  Or is it hypothetical?

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 May 2014 14:25:00 +0000

Hi Ralph:

" it was not expected that the device would have multiple addresses nor would renew them anytime soon..." comes from actual standards work, and is certain is those standards.
" the idea that the gateway would take care of issues is appealing" is just an idea (hypothetical), that extends the design that gateways do take care of all the issues for the devices, and that it would be good that the gateway falls from L5 to L3. 

Also, I noticed that usually there is a local transport end point in the vicinity (a fog server) so the devices themselves are not expected to reach far into the Internet. 

Cheers,

Pascal

> From: Ralph Droms [mailto:[email-masked]]
> Sent: vendredi 30 mai 2014 15:50
> Cc: Lemon Ted; [email-masked]
> > In the discussions I had earlier, Ted, it was not expected that the device
> would have multiple addresses nor would renew them anytime soon...
> Pascal - do you know of any specific protocols or specifications where this
> behavior (in which the gateway uses NPTv6 to translate between a ULA
> prefix in the LLN and an external GUA) is explicitly defined or required
> today?  Or is it hypothetical?
> 
> - Ralph
> 
> >
> > Cheers,
> >
> > Pascal
> >
> >
> >>> All in all, ULA is certainly very suitable in an LLN and a ML subnet
> >>> that
> >> federates a number of such.
> >>
> >> network and the rest of the world will be doing translation anyway,
> >> and hence it can deal with that complexity?
> >

---

From: Ralph Droms <[email-masked]>
Date: Fri, 30 May 2014 11:21:22 -0400

> " it was not expected that the device would have multiple addresses nor would renew them anytime soon..." comes from actual standards work, and is certain is those standards.

Pascal, I'd like to pull on this thread a little because I think it's important for this use case to know which are currently spec'ed use cases and which are hypothetical.  The Wi-SUN FAN spec requires each node to manage at least two prefixes, to allow for two LBRs improving availability.  My recollection is that the Z-IP spec expects nodes to manage multiple prefixes (I can look back in the text to confirm).  Are there other specs that specifically consider nodes that can only manage one prefix to be compliant with the spec?

> " the idea that the gateway would take care of issues is appealing" is just an idea (hypothetical), that extends the design that gateways do take care of all the issues for the devices, and that it…

Pulling on this thread as well, and looking specifically at the question Ted asked about multiple prefixes, I'm wondering how the use of a ULA would allow an LLN to operate more easily on a single prefix?  I'm assuming I have it right that NPTv6 does not enable one-to-many prefix translation.  The one use case I can think of is an LLN that uses two GUAs for make-before-break re-prefixing.  In the case of a ULA+NPTv6, a simple change in the NPTv6 translation table would implement the re-prefixing.  Avoiding re-prefixing with a ULA might save operational overhead and disruption, but I'd like to hear more about how using a single prefix would reduce the code and data overhead.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 May 2014 16:20:02 +0000

Hi Ralph:

Please see inline:

Cheers,

Pascal

> Sent: vendredi 30 mai 2014 17:21
> > " it was not expected that the device would have multiple addresses nor
> would renew them anytime soon..." comes from actual standards work, and
> is certain is those standards.
> 
> Pascal, I'd like to pull on this thread a little because I think it's important for
> this use case to know which are currently spec'ed use cases and which are
> hypothetical.  The Wi-SUN FAN spec requires each node to manage at least
> two prefixes, to allow for two LBRs improving availability.  My recollection is
> that the Z-IP spec expects nodes to manage multiple prefixes (I can look back
> in the text to confirm).  Are there other specs that specifically consider
> nodes that can only manage one prefix to be compliant with the spec?
> 
[PT] 
ISA100.11a relies on the backbone router functionality to cover that reliability issue. In that model all the RPL roots are part of a same multilink subnet federated by an IPv6 backbone. 6TiSCH is inheriting that model. There is no need for 2 prefixes, and you can have more than 2 exits for your mesh.

People at ISA100 were concerned with the size of a single IPv6 address; each device has a link local and a global but really the link local only appears in the compressed form in the join packet, and there is not much state associated to it in the device but the MAC address itself...

In fact, the ISA100 model exploits duocast where a second backbone router close to the first one can promiscuously hear the frame and send a copy over the backbone. 

> > " the idea that the gateway would take care of issues is appealing" is just
> an idea (hypothetical), that extends the design that gateways do take care of
> all the issues for the devices, and that it would be good that the gateway
> falls from L5 to L3.
> 
> Pulling on this thread as well, and looking specifically at the question Ted
> asked about multiple prefixes, I'm wondering how the use of a ULA would
> allow an LLN to operate more easily on a single prefix?  I'm assuming I have
> it right that NPTv6 does not enable one-to-many prefix translation.  The one
> use case I can think of is an LLN that uses two GUAs for make-before-break
> re-prefixing.  In the case of a ULA+NPTv6, a simple change in the NPTv6
> translation table would implement the re-prefixing.  Avoiding re-prefixing
> with a ULA might save operational overhead and disruption, but I'd like to
> hear more about how using a single prefix would reduce the code and data
> overhead.
> 
[PT] My expectation is that a device rarely needs to talk outside the ULA domain. 

If it does, there are models such as the NAP model that I indicated earlier in that thread where the device can get an external (home) address but that address would not need to be routed inside the LLN. And yes in such cases the device needs multiple addresses, the ULA that is routed inside the LLN and one or more GUA that are visible externally. NPTv6 will not work for ISA100 devices because the NPT device cannot fix the ISA100 (DTLS like) Message Integrity Check. The MIC incorporates the UDP header and the UDP pseudo header in the dataset that is signed with a transport layer session key.

The only thing that bars the LLN from having no real prefix at all is the UDP checksum or equivalent MIC signature that has to be performed by the device. Otherwise we'd end up with a similar result as with NAP. The device could have a null prefix or a well-known ULA prefix and let the NPT/HA border router decide what the external prefix is. In that case the renumbering only happens at the border router anyway, either as a decaps or as a translation. 

2 different border routers could mean multihoming, which can be done more or less cleanly and disruptively WRT to active sessions. With traditional CoAP, there is no such thing so the loss would be minimal. With Observe, things could become rough but the fault is on observe which is too far in its current incarnation from the REST of CoAP.

Cheers,

Pascal
> >
> > Also, I noticed that usually there is a local transport end point in the
> vicinity (a fog server) so the devices themselves are not expected to reach far
> into the Internet.
> >
> > Cheers,
> >
> > Pascal
> >
> >
> >> Pascal - do you know of any specific protocols or specifications
> >> where this behavior (in which the gateway uses NPTv6 to translate
> >> between a ULA prefix in the LLN and an external GUA) is explicitly
> >> defined or required today?  Or is it hypothetical?
> >>
> >> - Ralph
> >>
> >>>
> >>> Cheers,
> >>>
> >>> Pascal
> >>>
> >>>
> >>>>> All in all, ULA is certainly very suitable in an LLN and a ML
> >>>>> subnet that
> >>>> address issue--does it make sense for a 6lowpan node to have
> >>>> multiple addresses, or is the expectation that the gateway between
> >>>> the 6lowpan network and the rest of the world will be doing
> >>>> translation anyway, and hence it can deal with that complexity?
> >>>

---

From: Ralph Droms <[email-masked]>
Date: Fri, 30 May 2014 14:23:53 -0400

Thanks for the clarifications, Pascal.

- Ralph

> On May 30, 2014, at 12:20 PM, "Pascal Thubert (pthubert)" <[email-masked]> wrote:
> 
> Hi Ralph:
> 
> Please see inline:
> 
> Cheers,
> 
> Pascal
> 
>