Subject: [nat66] Terminology

From: RJ Atkinson <[email-masked]>
Date: Fri, 03 Apr 2009 10:37:15 -0400

Gentle People,

   At the 6AI BOF held at IETF last week, there seemed to be
rough consensus on the definitions for these 2 terms:

IPv6 NAT:	Generic term for any sort of NAT/NAPT/SAT
		for IPv6::IPv6 deployment

NAT66:		Precise, specific, term for the proposal
		documented in draft-mrw-behave-nat66-*.txt

   I think it would enhance clarity of communication and also
improve understanding if we could all use those terms in the
same way on this list as we tried to use them during the 6AI BOF
at IETF last week.

Thanks,

Ran Atkinson
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Apr 2009 10:45:23 -0400

>         documented in draft-mrw-behave-nat66-*.txt

I think it's useful to be able to describe not just IPv6-to-IPv6 NAT,
but any kind of NAT between IPvx and IPvy.  Since there's already some
established use for NAT66 and some other examples of that pattern, I
suggest we use the pattern xyNAT for NATs between x and y.

(I further suggest that we _not_ author any specific proposals with
names of the form xyNAT.)

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 3 Apr 2009 10:50:06 -0400

> for IPv6::IPv6 deployment

Perhaps a NIT, but from my IEEE experience: IPv6NAT. A single proper 
noun versus a NAT variant or a IPv6 bump in the roadmap. For our 
purposes, the proper noun is better.

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

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 3 Apr 2009 11:00:11 -0400

> suggest we use the pattern xyNAT for NATs between x and y.

But aren't 6-6 and 4-6 special gateway cases that have to do special 
things anyway and calling them NATs, while technically correct, masks 
their larger role? They are REALLY needed in the 4/6 transition scheme 
of things.

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Apr 2009 11:04:24 -0400

> their larger role? They are REALLY needed in the 4/6 transition scheme

It may be that there are actually cases where 66NAT is the best way to
solve a valid problem, given the current constraints elsewhere in the
architecture.  (I think the jury is still out on those, but I'm trying
to keep an open mind about them.)

Also, IMHO, if we're going to have NATs in the architecture (I did say
"if"), we need to start encouraging some uniformity of behavior between
them, and work toward providing a predictable, location-independent
programming model for applications.  The current hodgepodge approach to
trying to solve every xyNAT problem separately just threatens to make
the Internet even more unpredictable (i.e. hostile) to applications than
it is now.

So I really do hope to encourage people to think about NATs in general
rather than as lots of different special cases.

Keith

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Apr 2009 08:55:06 -0700

> suggest we use the pattern xyNAT for NATs between x and y.

Yes. But the problem is that NAT46 and NAT44 are also specific  
proposals, and NAT66 actually *is* a specific proposal. I'm with you  
on wanting a generic name, but trying to coopt the names of specific  
proposals as generic names just confuses things. Please stop confusing  
things.

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Apr 2009 08:56:07 -0700

On Apr 3, 2009, at 8:00 AM, Robert Moskowitz wrote:

> things anyway and calling them NATs, while technically correct,  
> masks their larger role? They are REALLY needed in the 4/6  
> transition scheme of things.

While Marcello's proposal is called NAT46, it is not actually a  
network address translator. It is an Internet Protocol Translator.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 3 Apr 2009 12:11:53 -0400

Fred Baker wrote:
>> their larger role? They are REALLY needed in the 4/6 transition 
>> scheme of things.
>

Thank you Fred, that is kind of what I meant to convey. 4-6 and 6-4 have 
a lot more work to do and calling them NATs is very misleading. So I 
guess we have to get NAT46 a different name ;)

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 03 Apr 2009 12:16:27 -0400

Keith,

   You were present for 6AI.  You heard the general agreement
in the room to the terminology outlined in my previous note.
You objected to many things said during the 6AI BOF, but
not to the terminology that I outlined in my previous note
to this list.

   Please don't try to re-negotiate terminology now, and
please don't undertake a DOS attack on this mailing list
by persuing some different approach.

Thanks,

Ran

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 03 Apr 2009 12:38:56 -0400

wanted to get my two cents in on a couple topic brought up on this 
thread as well as the "case for SAT66..."

1.  while it may be too late to clear up all the confusion, it would be 
useful to have generic terms for the various types of translators, and 
more specific names for specific solution proposals based on 
distinguishing characteristics.  NAT66 sounds like a generic name to me; 
the name should reflect some specifics of the proposal.
2.  I agree with the characterization of "stateless" to mean no 
connection-specific state; configuration and setup do not constitute 
"state" in this sense. The tension at the BOF indicates a lack of 
consensus on this definition.  That should be clarified too.
3.  I agree that Margaret's proposal could be called "stateless" address 
translation, or stateless prefix translation, something more specific 
and descriptive than NAT66.  Assuming that there may be other competing 
solutions to NAT for IPv6 (with different characteristics.)

Constructively, this discussion can go on for a few more days to "let 
1000 flowers bloom" regarding what to call everything, but at some point 
the chairs should call "time", collect the proposals, and figure out a 
way to make a firm decision on naming conventions.  We probably need (in 
some cases already have) generic names for address translation 
(IPv4-only, IPv6-only) and IPv4-IPv6 protocol translation, and may need 
to rename some specific proposals to disambiguate.  There is a lot of 
overlap between this BOF, 6man, v6ops, softwire and behave - so all 
those groups would have to buy in to the naming convention or it won't 
mean anything.  The main question:  is this important enough to spend 
more intellectual capacity, or should we focus on documenting the real 
problems and potential solutions and let the naming take care of itself?

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Rémi Després <[email-masked]>
Date: Fri, 03 Apr 2009 19:09:04 +0200

>         documented in draft-mrw-behave-nat66-*.txt

This mail is sent privately to avoid heating more the debate on the 
NAT66 list. (BTW is it a list just for Margaret's proposal, or a list 
open to other ways to avoid some or all of the NAT44 pitfalls.)

I believe that it is in good faith that you thought that a large 
majority of others agreed on the understanding above. But AFAIK this was 
not the case.

Personally, I don't remember any significant time to discuss vocabulary 
at the 6AI BOF, and any test of consensus on this subject.
Please consider that my understanding, and Keith's, are also in good faith.

IMHO, preempting a generic name, which was already in use, for just one 
specific proposal (interesting but highly debatable), as Margaret seems 
to succeed doing,  doesn't render service to the community.

Regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 03 Apr 2009 19:16:08 +0200

> solutions to NAT for IPv6 (with different characteristics.)

As mentioned in slide 4 of Dan Wing in SF, draft-despres-sam-02 includes 
an alternative technical approach for the 6AI BOF.

Note that posted DAN's slides say that this draft was not published, but 
shown slides were corrected on this point. (The draft was posted on the 
24th, 2 days before the BOF meeting.)

Regards,

RD

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 03 Apr 2009 13:40:26 -0400

On  3 Apr 2009, at 13:09, Rémi Després wrote:
> But AFAIK this was not the case.

Remi,

The BOF Chairs specifically agreed during the 6AI
meeting that the terminology I outlined was what
ought to be used.

Yours,

Ran

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 3 Apr 2009 13:41:20 -0400

> open to other ways to avoid some or all of the NAT44 pitfalls.)

The BOF was introduced as being for any NAT solution for IPv6 to IPv6, 
and Margaret's was used as a DISCUSSION point to see if a wg would be 
formed.

> majority of others agreed on the understanding above. But AFAIK this 
> was not the case.
>
> Personally, I don't remember any significant time to discuss 
> vocabulary at the 6AI BOF, and any test of consensus on this subject.

There was a hum that a generic term was appropriate, or some such hum.  
Ran did go to the mike once to ask for care in terminology.  Margaret 
had already obsconded ( :) ) with NAT66 for her specific solution, so 
the group needed a different generic one.

> IMHO, preempting a generic name, which was already in use, for just 
> one specific proposal (interesting but highly debatable), as Margaret 
> seems to succeed doing,  doesn't render service to the community.

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Apr 2009 16:28:12 -0400

> by persuing some different approach.

Ran,

I am trying to make a suggestion for how to move forward by suggesting
that for generic terms we use terms that aren't overloaded (xyNAT rather
than NATxx) and you are accusing me of malice.

You owe me, and the group, an apology.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Apr 2009 16:32:52 -0400

Fred Baker wrote:
> proposals, and NAT66 actually *is* a specific proposal. I'm with you on
> wanting a generic name, but trying to coopt the names of specific
> proposals as generic names just confuses things. 

That's why I'm proposing to use xyNAT - to _distinguish_ the generic
name from specific proposals which have names of the form NATxy.

Keith

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Apr 2009 12:06:45 -0700

> name from specific proposals which have names of the form NATxy.

There is a fundamental issue there, though.

IPv4/IPv4 is network address translation - stateful, per flow

IPv4/IPv6 is network protocol translation, and has both stateless and  
stateful modes with different operational and service characteristics.

IPv6/IPv6 could be IPv4/IPv4 redux, but at least the NAT66 proposal is  
not that. It is network *prefix* translation, and is stateless. It, by  
virtue of doing the TCP/UDP checksum update in the IPv6 address,  
enables IPsec ESP sessions (AH won't work, and apart from that  
encrypted sessions don't work with ESP, and even unencrypted sessions  
are a PITA due to the antics required to find the TCP header).

So, please, I really don't want people using one acronym that by  
accident has the right first letters to dump all of these in one box.  
They are not the same, and the use of the same acronym makes it easy  
for us to unconsciously lump them all in the same bucket

Since I haven't come up with good acronyms (I can do SAT for the NAT66  
flavor, but Margaret doesn't like it), I have taken the approach of:

    - I call anything with per-flow dynamic state a NAT
    - I call IPv4/IPv6 protocol translation "IPv4/IPv6 protocol  
translation"
    - I call NAT66 "NT66"
    - I call more generic IPv6/IPv6 prefix translation "IPv6/IPv6  
prefix translation"

Until someone comes up with a less confusing approach, I would suggest  
we likewise be clear in our comments.

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 08 Apr 2009 15:34:14 -0400

On  8 Apr 2009, at 15:06, Fred Baker wrote:
> [NAT66] by virtue of doing the TCP/UDP checksum update in the
> IPv6 address, enables IPsec ESP sessions (AH won't work, and
> apart from that encrypted sessions don't work with ESP,
> and even unencrypted sessions are a PITA due to the antics
> required to find the TCP header).

   There is a widely deployed mechanism for IPv4 NAT traversal
(i.e. RFC-3948 -- UDP encapsulation of IPsec).  This is available
in nearly all hosts, and no special firewall/NAT/transit-router
support is needed to use it.

   That same mechanism works fine for a very wide range of IPv6 NAT
mechanisms, including but not limited to NAT66.

   We should use that (short-term) for all IPv6 NAT traversal
with IPsec as it is available and works, and it does not depend
upon some particular feature of a particular IPv6 NAT approach.

   It isn't worth the time or energy to try to do something
more complex with any of the IPv6 NAT solutions, because the
end systems can't ordinarily know whether an IPv6 NAT is
present nor which IPv6 NAT approach might have been deployed
in a particular location.

   In the longer term, the IETF community should revise the
"IPsec for IPv6" specifications so that the IPv6 routing prefix
(specifically the high-order 64 bits) is included neither in the
IPv6 IPsec Security Associations, nor in the AH calculations,
nor in IKE or the IKE DOI for IPv6 IPsec.  [It has been broadly
unfortunate that the IESG insisted on moving the AH/ESP work
out of IPng WG and into IPsec WG in the middle-1990s; lots of
unfortunate consequences came from that decision, including
these items that ought to be fixed.]

Cheers,

Ran