Subject: [nat66] The case for the name SAT66 to mean stateless NAT66

From: Rémi Després <[email-masked]>
Date: Wed, 01 Apr 2009 15:16:45 +0200

This is a contribution to the debate on which NATs may be useful in 
IPv6, how simplified they can be, and how to name them.

1. IF we want to support _IPv6-only hosts in sites having only private 
IPv6 local addressing, we DO NEED some _address modification in CPEs_.

(Whether this support could be limited to common applications that don't 
need  ALGs like the Web, e-mail and the DNS can remain an open question 
here.)

2. In IPv6, we know this modification CAN BE limited to a stateless 
prefix substitution.

3. We then NEED a name for such a degenerate NAT.

Expecting that IETF can force people to use the name NAT66 only for such 
a degenerate NAT is unrealistic because stateful NAT66s will obviously 
also exist:
- Deriving a stateful NAT66 from a NAT44 is almost trivial.
- Some say it has already been done
- Using stateful NAT66 for address amplification is advocated as useful 
in specific cases.

It has been suggested in the past that purposely avoiding to name 
stateless IPv6 NATs might be judicious for some tactical or marketing 
reasons. But maintaining confusion is NOT what is expected from IETF.

5. I therefore propose that the stateless IPv6 NAT be named _SAT66_ 
(IPv6 to IPv6 Stateless Address Translation).

- Like NAT, SAT is easy to pronounce and has the same number of letters 
for easy substitution in pictures an documents.
- The essential characteristic of being stateless is expressed in the name.

I would really hope that those who share this understanding support that 
we clarify what we talk about.

Regards,

RD

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 1 Apr 2009 09:38:19 -0400

Hi Remi,

On Apr 1, 2009, at 9:16 AM, Rémi Després wrote:
>
> Expecting that IETF can force people to use the name NAT66 only for  
> such a degenerate NAT is unrealistic because stateful NAT66s will  
> obviously also exist:
> - Using stateful NAT66 for address amplification is advocated as  
> useful in specific cases.

I think we have some disagreement about the meaning/scope of the term  
"NAT66".

In my experience, the terms NAT44, NAT64, NAT46 and NAT66 are the  
_names_ of specific IETF proposals.  The terms IPv4 NAT and IPv6 NAT  
are used to generically identify IPv4-to-IPv4 NAT devices and IPv6-to- 
IPv6 NAT devices, respectively.

If you enter "NAT66" in Google, you will get many hits.  The first two  
pages of hits refer to the IETF NAT66 proposal.  By page 3 or 4, you  
will start to get other hits for NAT66, none of which refers to a  
Network Address Translator at all.

If you enter "IPv6 NAT" in Google, you get many hits referring to  
devices that perform network address translation in IPv6, most of  
which are not related to the NAT66 proposal.

So, I believe there is a good case for my position that generic IPv6- 
to-IPv6 NAT devices are called "IPv6 NATs", and that "NAT66" is a  
specific IETF proposal for how an IPv6 NAT could/should work.

> stateless IPv6 NATs might be judicious for some tactical or  
> marketing reasons. But maintaining confusion is NOT what is expected  
> from IETF.
>

One problem with this name is that a NAT66 device is _not_ stateless.   
It requires configured/static state to function -- at least the two  
prefixes between which it is translating.   When I say that the  
mapping is stateless, I mean that the mapping mechanism does not  
create or require dynamic (per-host, per-connection, etc.) state.

I also feel quite strongly that if we are going to define a type of  
IPv6 NAT, we should be clear (with ourselves and others) that that's  
what we're doing.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2009 09:42:35 -0400

Margaret Wasserman wrote:

> _names_ of specific IETF proposals.  The terms IPv4 NAT and IPv6 NAT are
> used to generically identify IPv4-to-IPv4 NAT devices and IPv6-to-IPv6
> NAT devices, respectively.

I've been using NAT66 as the generic name more than IPv6 NAT, which
seems more cumbersome.  But I could be convinced to use xyNAT as the
generic convention.

Whatever names are chosen, I think it's going to take some time to get
everyone to use them consistently.

Keith

---

From: Rémi Després <[email-masked]>
Date: Wed, 01 Apr 2009 16:23:04 +0200

Margaret Wasserman  -  le (m/j/a) 4/1/09 3:38 PM:
> devices that perform network address translation in IPv6, most of which 
> are not related to the NAT66 proposal.
> 
> So, I believe there is a good case for my position that generic 
> IPv6-to-IPv6 NAT devices are called "IPv6 NATs", and that "NAT66" is a 
> prefixes between which it is translating.   When I say that the mapping 
> is stateless, I mean that the mapping mechanism does not create or 
> require dynamic (per-host, per-connection, etc.) state.

This is the kind of confusing situation I wish to help avoiding: "it is 
stateless... but not stateless the way you thought".

How would we expect people to understand this outside a small initiated 
circle?

> 
> I also feel quite strongly that if we are going to define a type of IPv6 
> NAT, we should be clear (with ourselves and others) that that's what 
> we're doing.

I have difficulty understanding why the "stateless, transport-agnostic 
IPv6-to-IPv6 Network Address Translation", as you define it in your 
draft, could not be called "stateless NAT66", and SAT66 for short. 
(Unless there would be some NIH syndrome here, but I don't want to 
believe this could be the case.)

You quite usefully introduced the concept. What would be wrong in 
improving the name? (a "stateless" NAT isn't just a NAT, right?)

RD

---

From: Scott Brim <[email-masked]>
Date: Wed, 1 Apr 2009 11:30:22 -0400

Excerpts from Rémi Després on Wed, Apr 01, 2009 04:23:04PM +0200:
>> One problem with this name is that a NAT66 device is _not_
>> stateless.   It requires configured/static state to function -- at
>> least the two  prefixes between which it is translating.   When I
>> say that the mapping is stateless, I mean that the mapping
>> mechanism does not create or  require dynamic (per-host,
>> per-connection, etc.) state.
>
> This is the kind of confusing situation I wish to help avoiding: "it
> is  stateless... but not stateless the way you thought".
>
> How would we expect people to understand this outside a small
> initiated  circle?

By avoiding 'stateless'.  What Margaret said.  

NAT as traditionally conceived has per-host (and maybe per-session)
state.  NAT66 has per-prefix state.  I think it would be fine if you
found a good name that reflected that, but did not make any claims of
being state-free.

Scott

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Apr 2009 08:41:06 -0700

On Apr 1, 2009, at 6:38 AM, Margaret Wasserman wrote:

> least the two prefixes between which it is translating.

In the work in Behave, we have very carefully defined "state" to mean  
"dynamic state" as opposed to "configuration". RFC 2765, Stateless  
Address Translation, has configuration as well (at minimum it has to  
be turned on). I think Remi is using the same line of reasoning here.  
Yes, it uses configuration (of an inside and an outside prefix), but  
there is no per-flow or per-end-system state maintained. As a result,  
if I want to load-share across two identically-configured NAT66  
devices, I don't need to coordinate - they both have the information  
they need to come up with the same result.

> are used to generically identify IPv4-to-IPv4 NAT devices and IPv6- 
> to-IPv6 NAT devices, respectively.

I agree, and at the same time I am aware that people use these terms  
in a generic sense. In the behave context, I am trying to replace both  
the names IVI and NAT46 (which are names of specific proposals) with  
reference to IPv4/IPv6 translation, and am getting pushback that "that  
is generically called NAT46", which happens to be the name of one  
document in a four document set. It is very confusing.

I agree that we are better talking about "IPv4/IPv4 NAT", "IPv6/IPv6  
something", and "IPv4/IPv6 translation" as the generic terms.

That said, I think Remi has made a good suggestion here. Calling it  
Stateless Address Translation makes sense, I think.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 1 Apr 2009 18:49:29 +0300

> - Using stateful NAT66 for address amplification is advocated as useful

Sorry. You're simply too late. Stateless NAT already exists, in IPv4 world, 
today and the terminology is already used. Those are particular efficient and 
seducive for 1:1 port forwarding for instance.

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

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: Rémi Després <[email-masked]>
Date: Wed, 01 Apr 2009 17:53:51 +0200

> By avoiding 'stateless'.  What Margaret said.  

Margaret and Fred also say, in the abstract of their draft, that they 
describe "a stateless, transport-agnostic IPv6-to-IPv6 Network Address 
Translation", in brief a stateless NAT.

This makes IMHO a lot of sense: this is what it is.
> found a good name that reflected that, but did not make any claims of

Consider also that RFC 2765 defines the "Stateless IP/ICMP Translation 
Algorithm (SIIT)" with more static parameters for address translation 
than the two prefixes of the stateless NAT66.

I hope that, in view of these facts, you could accept that the word 
stateless, rather than being avoided, should be used to keep things 
clear, consistent, and simple.

Regards,

RD

---

From: james woodyatt <[email-masked]>
Date: Wed, 1 Apr 2009 08:56:07 -0700

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

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

---

From: Rémi Després <[email-masked]>
Date: Wed, 01 Apr 2009 17:57:29 +0200

> Stateless Address Translation makes sense, I think.

I do believe it will help if we can make such a change as early as possible.
Thanks,
RD

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 1 Apr 2009 14:44:37 -0400

On Apr 1, 2009, at 11:53 AM, Rémi Després wrote:
>
> Margaret and Fred also say, in the abstract of their draft, that  
> they describe "a stateless, transport-agnostic IPv6-to-IPv6 Network  
> Address Translation", in brief a stateless NAT.

Yes, but the use of the term "stateless" seemed to cause considerable  
confusion at the BOF.  I do learn from experience, and I think we  
should be clearer about what we mean than simply calling NAT66  
"stateless".

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 1 Apr 2009 14:52:27 -0400

Hi Remi,

> I do believe it will help if we can make such a change as early as  

You believe that changing the name will help _what_?

At this point, we have made a proposal to the IETF for an IPv6-to-IPv6  
NAT, and we've called it NAT66.  If an IETF WG takes on this proposal  
and has consensus to change its name, that's totally fine with me.   
Right now, though, there are a few people who want to change the name  
(although there isn't agreement about what we should call it instead)  
and there are a few people who want to keep the name the same.  So, I  
don't see any consensus to change the name, nor have I been offered a  
compelling reason to do so.

Perhaps it would be better to focus this discussion on the technical  
aspects of this proposal, instead of focusing on its name?

Margaret

---

From: JFC Morfin <[email-masked]>
Date: Thu, 2 Apr 2009 13:39:44 +0200

May introduce a user opinion here?
End-users go by the box they (are to) buy. Lead-users go by the box they
enhance.
- in the first case there should be a clear table of functions by a clear
list of box names, indicating which function  is included or not in each box
name.
- in the second case, the number of functions to be supported is limitless,
so the name is to be generic and refer to the location of the box in the
network. The name IUCG uses is "interbox".

So, an interbox is a generic evolutive physical/logical box that can gather
many smart gateway functions that are documented as physical/logical
specific named boxes.

This makes then sense then that each new function can be specified and
tested under a box name (NAT66, NAT64, STAT66, etc.) and/or encapuslated in
interboxes. People interboxes are/will be understood as the permanent IP
gateway to whatever IPv4/6 network system they may have set-up under IPv4 or
IPv6. They will most probably include services such as multilevel addressing
and naming management, registry servers, firewall, ONES/OPES shims, DDDS
semantic converters, [GR]IDv6 routers, until we have a true network
interoperation system (what we call Netix, a concept users understand
easily), etc.

IMHO if you want people to buy IPv6 you have to proceed as sales do:

- first to sell yourselves: make people accept you are credible,
- then to make them dream about what they will be able to do with your
proposition (be extremly clear about what they can dream of, because they
have to get aroused by what they feel they can do more with the next box
they get,
- then do not "violate" too much: make the transition easy in selling the
box to the ISP, users will have to be incitated into the change by the
"plus" their ISP will propose them. This is what IUCG calls "Internet PLUS"
(parallel layered users systemic) more functions being permitted at each
layer due to forgeting past constraints the user is not interested in. Until
we extend the whole protocol pile to support the new functions.
- finaly make them feel they have made the good choice in accepting your
proposition (that means that the transition is seamless and that they get
more for their hassle of changing their system, than they expected).

Please, do not refer to anything old. People do not know about NATs, they
know about their ISP smart boxes. What they need to hear is about a general
new generation boxes, i.e. smart boxes becoming smart gateways. Do not talk
of "new internet", people need to feel secure and that the "new generation
internet" is the old internet they know and their friends use.

Please also remember that people are really important in all this because
they are the demand and the payers who will oblige providers to move. And
the market which will decide if your propositions are good.

Users do not care about IPv6. They never cared about IP, v4 or as V6,
because they never had a permanent IP address. So, there are only two
arguments they can be pleased with:

1. IPv6 means a permanent dedicated network number like the phone (but not
yet like the mobile, because "they" did not organised properly the numbering
plan yet) [talking of address to users confuses them, talking of number is
easier for them to understand and feel "confortable" with - the key word]

2. IPv6 means that they also can have billions of IIDs they can play with by
themselves, for example through IPv6 supported "IDv6", or with other with
general regions of IDv6 (GRIDv6), starting with plug and play, network
translation (as in memory translations), semantic access engines and
addresses, etc. What is important for the users is not what your boxes could
do, but what they feel confortable they can do themselves if they invest in
your boxes.

This means that Rémi Desprès is totally right in terms of semantic need, but
has an obvious difficulty to propose something that both users (me) and IETF
history (Margaret) can identify as the same thing.

I hope it helps.
jfc

2009/4/1 Margaret Wasserman <[email-masked]>

> At this point, we have made a proposal to the IETF for an IPv6-to-IPv6 NAT,
> and we've called it NAT66.  If an IETF WG takes on this proposal and has
> consensus to change its name, that's totally fine with me.  Right now,
> though, there are a few people who want to change the name (although there
> isn't agreement about what we should call it instead) and there are a few
> people who want to keep the name the same.  So, I don't see any consensus to
> change the name, nor have I been offered a compelling reason to do so.
>
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Apr 2009 14:24:01 +1300

>  So, I

It doesn't matter anyway. The media and the market will call it NAT,
if it's a box that, er, translates network addresses. Let's get
over it.

> aspects of this proposal, instead of focusing on its name?

Yes.

    Brian

---

From: Rémi Després <[email-masked]>
Date: Fri, 03 Apr 2009 15:49:21 +0200

> You believe that changing the name will help _what_?

As I said, it would help avoiding to create and maintain confusion (it 
was not a fools' day joke).

(There are and there will be NAT66s that are just NAT44s trivially 
augmented to support IPv6 addresses in their mapping tables. Expecting 
that they no longer would be authorized to be called NAT66, in full 
consistency with NAT44, NAT64, and NAT46, is completely unrealistic.)

> and has consensus to change its name, that's totally fine with me.  

If I get it right, you consider the word NAT66 has been preempted, and 
should be used only your particular proposal.

I don't think it would not be wise to agree.

BTW, note that before  draft-mrw-behave-nat66-00 was even posted the 
word NAT66 was used in a mail of Dan Wing, in which he said "NAT66 is 
still a third rail. I don't want to go there".

> aspects of this proposal, instead of focusing on its name?

Well, unless some others which to pursue now (choosing early a good 
enough terminology is also important in practice), I will leave the 
subject for the time being.

I will now keep using NAT66 as a generic term for IPv6-to-IPv6, and 
refer to your design as _MW-NAT66_, hoping that others might do the same 
to avoid a disturbing ambiguity.

Regards,

RD