Re: [v6ops] {Disarmed} Revised texts for ULA #3 NPTv6 Use Case

["Liubing (Leo)" <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, June 03, 2014 3:23 PM
To: Liubing (Leo)
Cc: v6ops WG; [e-mail]; Lorenzo Colitti; Owen DeLong; Ted Lemon; Brian E Carpenter; Lee Howard
Subject: Re: {Disarmed} Revised texts for ULA #3 NPTv6 Use Case

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

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


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