Subject: [v6ops] ULA #3 NPTv6 Use Case

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 29 May 2014 08:28:50 +0000

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 29 May 2014 18:02:15 +0900

Leo, Chairs,

in March we had a 24-message discussion on this, with, I think, clear lack
of consensus:
http://www.ietf.org/mail-archive/web/v6ops/current/msg18741.html

There was also a comment from then-chair John, pointing out an unresolved
technical issue that I don't think was ever resolved:
http://www.ietf.org/mail-archive/web/v6ops/current/msg18757.html

Do we have to go through that discussion again? Has new information come to
light on this issue? Is there reason to believe that the discussion will be
any different now that two months have passed?

If the answer to those questions is no, then I would like to propose that
we avoid debating this issue, because we have already debated it multiple
times, the last time quite recently, with - it seems to me - clear lack of
consensus. I doubt that things will go any different this time around, and
not having the debate and advancing the document would save the working
group time.

Thanks,
Lorenzo

On Thu, May 29, 2014 at 5:28 PM, Liubing (Leo) <[email-masked]>
wrote:

> 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.
>
> (Current draft link:
> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02)
>
> 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.
>
> 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
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 29 May 2014 09:32:18 +0000

Hi Lorenzo,

I know discussion on Question 1 (the resource-constrained use case) was controversial. It is ok for me to move it out, just a confirmation to the WG.

Question 2 (3GPP use case) is another case that hasn’t been discussed in v6ops, but had a decent discussion in 6man. My personal thought is it worth to be documented. (Again, just documenting it as a valid case, not promoting to use IPv6 NAT)
Question 3 is just derived from Q2, if we agree to document the 3GPP NAT case, then it might be better not binding to the specific NPTv6 mechanism.

I also agree we should focus on advancing the document. Thank you.

Regards,
Bing

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, May 29, 2014 5:02 PM
To: Liubing (Leo); [email-masked]
Cc: v6ops WG; Alexandru Petrescu; John Jason Brzozowski
Subject: Re: ULA #3 NPTv6 Use Case

Leo, Chairs,

in March we had a 24-message discussion on this, with, I think, clear lack of consensus: http://www.ietf.org/mail-archive/web/v6ops/current/msg18741.html

There was also a comment from then-chair John, pointing out an unresolved technical issue that I don't think was ever resolved: http://www.ietf.org/mail-archive/web/v6ops/current/msg18757.html

Do we have to go through that discussion again? Has new information come to light on this issue? Is there reason to believe that the discussion will be any different now that two months have passed?

If the answer to those questions is no, then I would like to propose that we avoid debating this issue, because we have already debated it multiple times, the last time quite recently, with - it seems to me - clear lack of consensus. I doubt that things will go any different this time around, and not having the debate and advancing the document would save the working group time.

Thanks,
Lorenzo

On Thu, May 29, 2014 at 5:28 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, All

#3 NPTv6 Use Case

Question 1:

Question 2:

Question 3:

Regards,
Bing

---

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

> Question 3 is just derived from Q2, if we agree to document the 3GPP NAT case, then it might be better not binding to the specific NPTv6 mechanism.

This just feels like the camel trying to sneak its nose under the tent to me.   The 3gpp use case is contrived: if a 3gpp operator wants to support this use case, they should send a shorter prefix.   If they only send a /64, then the node will only be able to support one subnet.   Essentially you are proposing to tweak the IPv6 addressing architecture here, and I don't think that's appropriate.   So I think you really should not address points 2 and 3.

---

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

> I know discussion on Question 1 (the resource-constrained use case) was controversial. It is ok for me to move it out, just a confirmation to the WG.

I've asked for some review from the IntArea directorate, and so far the one response I've gotten back, from someone who's implemented an LLN stack, is that RPL is by far more complicated than supporting multiple prefixes, and that while they do support ULAs for address stability during periods of disconnection, they support that alongside global addressing.

It would be useful to hear from more implementors.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 30 May 2014 01:28:04 +0000

Hi Ted,

Thanks much for the information. 
It seems the assumption of resource-constrained nodes couldn't support multi-prefixes is invalid. I'll delete the case in the draft.

Regards,
Bing

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Thursday, May 29, 2014 9:16 PM
> To: Liubing (Leo)
> Cc: Lorenzo Colitti; [email-masked]; v6ops WG
> Subject: Re: [v6ops] ULA #3 NPTv6 Use Case
> 
> > I know discussion on Question 1 (the resource-constrained use case) was
> controversial. It is ok for me to move it out, just a confirmation to the WG.
> 
> I've asked for some review from the IntArea directorate, and so far the one
> response I've gotten back, from someone who's implemented an LLN stack,
> is that RPL is by far more complicated than supporting multiple prefixes, and
> that while they do support ULAs for address stability during periods of
> disconnection, they support that alongside global addressing.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 30 May 2014 10:43:38 +0900

Chairs,

It seems that question 1 is now resolved. Before we discuss questions #2
and #3, I have not seen a response to my question about whether you believe
the working group should re-engage in this debate or not.

Should we consider Question #2 or #3? Or is it your reading that we've
discussed this recently with no consensus, that therefore there's no point
in discussing that again, and that the document should not cite a ULA+NPT66
use case?

Thanks,
Lorenzo

On Fri, May 30, 2014 at 10:28 AM, Liubing (Leo) <[email-masked]>
wrote:

> It seems the assumption of resource-constrained nodes couldn't support
> multi-prefixes is invalid. I'll delete the case in the draft.
>
> Regards,
> Bing
>

---

From: Owen DeLong <[email-masked]>
Date: Thu, 29 May 2014 18:52:54 -0700

I think this use case is absurd.

If you need to communicate to outside world, it’s perfectly reasonable to use SLAAC with GUA and there’s no benefit derived from ULA+NPT.

Owen

On May 29, 2014, at 1:28 AM, Liubing (Leo) <[email-masked]> wrote:

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 30 May 2014 10:58:32 +0900

Owen,

I said "BEFORE we discuss questions #2 and #3". :-)

The chairs have expressed concern that this document keeps getting mired in
debate. I'm trying to help. One way to avoid that is to avoid this
particular debate altogether.

Cheers,
Lorenzo

On Fri, May 30, 2014 at 10:52 AM, Owen DeLong <[email-masked]> wrote:

> If you need to communicate to outside world, it’s perfectly reasonable to
> use SLAAC with GUA and there’s no benefit derived from ULA+NPT.
>
> Owen
>
> > 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.
> >
> > 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
> > 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
> >