Subject: Re: [v6ops] ULA #3 NPTv6 Use Case

From: Tim Chown <[email-masked]>
Date: Sun, 1 Jun 2014 14:45:51 +0100

Hi,

On 30 May 2014, at 02:58, Lorenzo Colitti <[email-masked]> wrote:

> 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.

This was pretty much what draft-ietf-v6ops-enterprise-incremental-ipv6-05 did, which is being published soon. It does include a fairly minimal reference to NPTv6, and a reference to the ULA draft under discussion here. 

In the homenet arch text there’s again a fairly short paragraph referencing NPTv6, with a short ‘health warning’ later in the text, to quote:

  "Note that unlike private IPv4 RFC 1918 space, the use of ULAs does
   not imply use of an IPv6 equivalent of a traditional IPv4 NAT
   [RFC3022], or of NPTv6 prefix-based NAT [RFC6296].  When an IPv6 node
   in a homenet has both a ULA and a globally unique IPv6 address, it
   should only use its ULA address internally, and use its additional
   globally unique IPv6 address as a source address for external
   communications.  This should be the natural behaviour given support
   for Default Address Selection for IPv6 [RFC6724].  By using such
   globally unique addresses between hosts and devices in remote
   networks, the architectural cost and complexity, particularly to
   applications, of NAT or NPTv6 translation is avoided.  As such,
   neither IPv6 NAT or NPTv6 is recommended for use in the homenet
   architecture.  Further, the homenet border router(s) should filter
   packets with ULA source/destination addresses as discussed in
   Section 3.4.2.”

…

  "As explained previously, while NPTv6 has been proposed for providing
   multi-homing support in networks, its use is not recommended in the
   homenet architecture."

Perhaps something similar can be stated in this ULA draft.

Tim

> Cheers,
> Lorenzo
> 
> On Fri, May 30, 2014 at 10:52 AM, Owen DeLong <[email-masked]> wrote:
> 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:
> 
> > 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
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 2 Jun 2014 10:37:21 +0900

> Perhaps something similar can be stated in this ULA draft.

Having a statement in there that NPTv6 is experimental and not recommended
and not including use case that uses NPTv6 or NAT sounds good to me. But I
don't know if there we can reach rough consensus on such a statement.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 3 Jun 2014 03:38:18 +0000

Hi Dear all,

Based on recent discussion, I propose some revised texts as the following.
Please comment to see whether we can achieve consensus on this issue.

Many thanks!

Revised texts in Section 3.2.1:
“o  Using Network Prefix Translation

   Network Prefix Translation (NPTv6) [RFC6296] is an experimental
   specification that provides a stateless one to one mapping between
  internal addresses and external addresses. [RFC6296] considers translating
ULA prefixes into GUA prefixes as a use case. Although NPTv6 is not exactly
the same with the traditional stateful NAT/NAPT (which is discouraged in
[RFC5902]), it also introduces some similar additional complexity on many
applications, which might cause applications break.

So in general, this document doesn’t encourage to use ULA+NPTv6 (however,
some operational considerations are provided below for the ones who insist to
use ULA+NPTv6 for some reason). This document considers ULA+GUA as a better
approach to connect to the global network when ULAs are expected to be retained.
ULA+GUA is discussed in detail in Section 3.2.2 below.”

Original texts:
“o  Using Network Prefix Translation

   Network Prefix Translation (NPTv6) [RFC6296] is an experimental
   specification that provides a stateless one to one mapping between
  internal addresses and external addresses.

   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 document does not intend to encourage the ULA binding with NPTv6
   model, since in [RFC5902] the IAB had already gave opinions on IPv6
   NAT; but this document considers it as an effective approach in some
   specific situations as described above.”

________________________________

---

From: Owen DeLong <[email-masked]>
Date: Mon, 2 Jun 2014 22:31:20 -0700

This is a major improvement.

Owen

---

From: Tim Chown <[email-masked]>
Date: Tue, 3 Jun 2014 08:23:29 +0100

With a slight tidy up of language that could be:

"o  Using Network Prefix Translation
 
   Network Prefix Translation (NPTv6) [RFC6296] is an experimental
   specification that provides a stateless one to one mapping between
  internal addresses and external addresses. The specification considers translating
ULA prefixes into GUA prefixes as a use case. Although NPTv6 works differently
to traditional stateful NAT/NAPT (which is discouraged in [RFC5902]), it also
introduces some similar additional complexity to applications, which might cause 
applications to break.
 
Thus this document does not recommend the use of ULA+NPTv6. If an operator
does choose to use this approach, some operational considerations are provided 
below. Rather, this document considers ULA+GUA as a better approach to connect 
to the global network when ULAs are expected to be retained. The use of ULA+GUA 
is discussed in detail in Section 3.2.2 below.”
 
There’s certain a case to remove the “If an operator” sentence altogether.

I think there’s also some NPTv6 text in 3.2.1 that needs updating Bing.

Tim

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 3 Jun 2014 07:56:50 +0000

Hi Tim,

Thanks a lot for the text refining.
I’ll work through the document and make the NPTv6 description consistent when do the next version.

Best regards,
Bing

From: Tim Chown [mailto:[email-masked]]
Sent: Tuesday, June 03, 2014 3:23 PM
To: Liubing (Leo)
Cc: v6ops WG; [email-masked]; Lorenzo Colitti; Owen DeLong; Ted Lemon; Brian E Carpenter; Lee Howard
Subject: Re: {Disarmed} Revised texts for ULA #3 NPTv6 Use Case

Tim

On 3 Jun 2014, at 04:38, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dear all,

Many thanks!

Original texts: