Subject: Re: [nat66] naming issues

From: james woodyatt <[email-masked]>
Date: Fri, 29 Oct 2010 16:24:09 -0700

margaret--

I went through my archives of the list.  We've discussed the naming confusion issue before, but I don't think a consensus emerged.  Here's what I proposed:

Begin forwarded message:

> From: james woodyatt <[email-masked]>
> Date: April 1, 2009 08:56:07 PDT
> To: [email-masked]
> Subject: Re: [nat66] The case for the name SAT66 to mean stateless NAT66
> 
> On Apr 1, 2009, at 08:41 , Fred Baker wrote:
>> 
>> That said, I think Remi has made a good suggestion here. Calling it Stateless Address Translation makes sense, I think.
> 
> I could accept either of the following as improvements to the existing order:
> 
>  + Stateless IPv6-to-IPv6 Address Translation (SAT66)
>  + IPv6 Network Prefix Translation (6NPT)
> 
> I prefer the latter term, but the former is fine too.
> 
> I'd prefer either of these over NAT66 on the grounds that I expect it to be easier to teach people that this new and different thing they've never heard of before still breaks some applications, than to try to teach people that conventional NAT44 means dynamic per-host state, NAT64 means dynamic per-host state, but NAT66 means no dynamic state.
> 
> On Apr 1, 2009, at 08:49 , Rémi Denis-Courmont wrote:
>> 
>> "NAT" does not mean that it's stateful or stateless. It means it's doing translation. Using a separate word for stateless IPv6-IPv6 NAT will just add to the confusion at this point.
> 
> Another reason I prefer IPv6 Network Prefix Translation (6NPT).  It still says translation, but it explicitly constrains the translation to network prefixes only.

When the latest revision of I-D.mrw-nat66 appeared and the name had not changed, I assumed that we were still using NAT66 to refer specifically to the proposal in the draft we have, and that we do not yet have a good way to refer to the sort of IPv6 network address/port translation that Mr. Engel and Mr. Marquis have been so vigorously advocating on the list recently.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 29 Oct 2010 19:37:39 -0400

Hi James,

I didn't read this before posting my previous message...  Would  
"Algorithmic NAT66" address your concern?  Because I do think that is  
the main way in which this is different form regular old NAPT44, or an  
IPv6 equivalent.

What do you think?

Margaret

On Oct 29, 2010, at 7:24 PM, james woodyatt wrote:

> margaret--
>
> I went through my archives of the list.  We've discussed the naming  
> confusion issue before, but I don't think a consensus emerged.   
> Here's what I proposed:
>
> Begin forwarded message:
>
>>> That said, I think Remi has made a good suggestion here. Calling  
>>> it Stateless Address Translation makes sense, I think.
>>
>> I'd prefer either of these over NAT66 on the grounds that I expect  
>> it to be easier to teach people that this new and different thing  
>> they've never heard of before still breaks some applications, than  
>> to try to teach people that conventional NAT44 means dynamic per- 
>> host state, NAT64 means dynamic per-host state, but NAT66 means no  
>> dynamic state.
>>
>>> "NAT" does not mean that it's stateful or stateless. It means it's  
>>> doing translation. Using a separate word for stateless IPv6-IPv6  
>>> NAT will just add to the confusion at this point.
>>
>> Another reason I prefer IPv6 Network Prefix Translation (6NPT).  It  
>> still says translation, but it explicitly constrains the  
>> translation to network prefixes only.
>
> When the latest revision of I-D.mrw-nat66 appeared and the name had  
> not changed, I assumed that we were still using NAT66 to refer  
> specifically to the proposal in the draft we have, and that we do  
> not yet have a good way to refer to the sort of IPv6 network address/ 
> port translation that Mr. Engel and Mr. Marquis have been so  
> vigorously advocating on the list recently.
>
>
> --

---

From: james woodyatt <[email-masked]>
Date: Fri, 29 Oct 2010 16:57:16 -0700

On Oct 29, 2010, at 16:37, Margaret Wasserman wrote:

> I didn't read this before posting my previous message...  Would "Algorithmic NAT66" address your concern?  Because I do think that is the main way in which this is different form regular old NAPT44, or an IPv6 equivalent.
> 
> What do you think?

Sure, and I agree with you.  My main concern is that I think we need a term that conveys the kind of IPv6/NAT that Mr. Engel and Mr. Marquis et al. are demanding, apart from the one described in the I-D.mrw-nat66 draft, and it seems like NAT66 is quickly coming to be used widely for that purpose.

One imagines that "algorithmic NAT66" will get shortened down to ALGO-NAT66 or something like that.

I'm also okay if ALGO-NAT66 is regarded as a strict subset of NAT66.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 30 Oct 2010 00:13:17 +0000

> I'm also okay if ALGO-NAT66 is regarded as a strict subset of NAT66.

The current proposal is interesting precisely because it is a subset of the entire universe of NAT66: it is stateless, and it does not include port mapping. At some level, if you hold your nose long enough, it feels like some kind of tunnel.

I wish it could be an antidote against more complex forms of translation. 

For that, I wonder whether we should include some form of topology hiding in the solution, or at least topology obfuscation. I know that it can be done, e.g. using some form of encryption of the EID during translation, with the effect of obfuscating the subnet mapping. 

Of course, if we did include topology obfuscation, we would lose the simple "prefix mapping" property. So we would probably leave that as an option.

-- Christian Huitema

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 30 Oct 2010 16:23:03 -0400

Hi Christian,

On Oct 29, 2010, at 8:13 PM, Christian Huitema wrote:
> The current proposal is interesting precisely because it is a subset  
> of the entire universe of NAT66: it is stateless, and it does not  
> include port mapping. At some level, if you hold your nose long  
> enough, it feels like some kind of tunnel.

Exactly, it is more like a tunnel that avoids MTU/fragmentation issues  
than a NAT.

> For that, I wonder whether we should include some form of topology  
> hiding in the solution, or at least topology obfuscation. I know  
> that it can be done, e.g. using some form of encryption of the EID  
> during translation, with the effect of obfuscating the subnet mapping.
>
> Of course, if we did include topology obfuscation, we would lose the  
> simple "prefix mapping" property. So we would probably leave that as  
> an option.

I had a topology hiding option in the first version of NAT66, where a  
reversible (with the key) cryptographic transform was performed on the  
subnet bits and IID before the checksum correction was performed.  I  
was pretty excited about that option, but all it turned into in the  
end was a lengthy presentation by someone from the security area about  
how obscuring the subnet and IID fields doesn't give you _true_  
topology hiding, because it doesn't hide things like TCP inter-packet  
timing, or whatever.

So, I took the topology hiding mechanism out, because it seemed like  
something that would stand in the way of getting IETF consensus on the  
basic NAT66 mechanism.  But, if we can agree to a basic NAT66  
mechanism, it should be fairly easy to augment it with a topology  
hiding option.

Margaret