Subject: Re: [BEHAVE] interim meeting minutes

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 1 Jun 2009 17:36:25 +0200

On 1 jun 2009, at 8:06, Xing Li wrote:

>> I would prefer to keep "NAT" for stateful unless specifically  
>> indicated that it's stateless. We could keep SIIT for stateless  
>> translation.

> SIITbis? since it is different from the original SIIT.

Well, we usually call BGP4 "BGP" and HTTP/1.1 "HTTP", so I don't see a  
problem simply using "SIIT" unless we specifically need to point out  
that we're talking about the updated version.

We may want to avoid making a version 2 of NAT64 because NAT642 would  
be a bit confusing...

Iljitsch

---

From: Rémi Després <[email-masked]>
Date: Mon, 1 Jun 2009 19:08:08 +0200

Le 30 mai 09 à 17:14, marcelo bagnulo braun a écrit :

> I personally think that the common understanding of the word NAT  
> todya is a device that is statefull and translates  not only  
> addresses but also ports.

Although it is true that most existing NATs are stateful, i.e. are  
NAPTs, I don't believe NAT is  "commonly understood" as only  
stateful. For example:
- In RFC 2663, a NAT is either stateless ("Basic NAT") or stateful  
(NAPT)
- In Margaret Wasserman's proposed IPv6 NAT,  NAT66 stands for a  
stateless function.

> for that reason, i believe that using the expression NAT64 and  
> NAT46 highlight the main difference with current NATs, i.e. that  
> they translate IPv6 to and from IPv4 and in the case of 64 they  
> support communications iniciated from the IPv6 side and in the case  
> of 46 they support communications initiated from the IPv4 side.

There can be NAT64s that are stateless,  with IPv4 addresses derived  
from IPv6 internal addresses.
"NAPT64" can name unambiguously what you propose to call NAT64.

> I think that the stateless translator is a very different device  
> from the most common version of IPv4 nats, since they are  
> stateless, so i think it makes sense to name it with a different  
> name that highlights the fact that they are stateless. I think  
> SIIT, stateless translator, even stateless IPv4/IPv6 translators  
> make sense.
>
> I also think that we need to have a short name for these things, in  
> particular, i think we need an acronym, rather than a phrase.

  As far as a stateless NAT is concerned, I share the view that SIIT  
is more intuitive than the "Basic NAT" of RFC 2663 (especially since  
most NATs are in fact NAPTs).

  Where external and internal address families are not implicit in  
the context, they could be indicated with a NATxy notation, with (x  
internal, y external.
  For example:
- Basic NATs of RFC 2663 could be referred to as SIIT44s
- Margaret's NAT66 proposal would be referred to, more precisely, as  
an SIIT66 proposal (stateless variant of NAT66).

> So, i would go for:
>
> Long name: stateless IPv4/IPv6 translation, short name SIIT
> Long name: Stateful NAT64, short name NAT64
> Long name: Stateful NAT46, short name NAT46

If it can be accepted that stateful NAT64 is named NAPT64, we can  
get, quite naturally IMHO:

NAT = NAT44, NAT64, or NAT46   (First and second digits are  
respectively those of internal and external address families. The NAT  
is sateless or stateful)
NAT44 = SIIT44 and/or NAPT44
NAT64 = SIIT64 and/or NAPT64
NAT46 = SIIT46 and/or NAPT46
NAT66 = SIIT66 and/or NAPT66

As an additional proposal, an NAT that is restricted to connections  
initiated from one side could de referred to as NATx>y, if  
connections are only internal to external,  or NAPTx<y  if  
connections only external to internal, so that:
-  a NAPT44 that supports only internal to external connections, i.e.  
supporting neither UPnP nor NAT-PMP, can be referred to as a NAT4>4,  
and even more precisely as a NAPT4>4
- a NAT46 that would support only external to internal connections  
could be referred to as a NAT4<6 or a NAPT4<6.

Regards,

RD

---

From: Xing Li <[email-masked]>
Date: Tue, 02 Jun 2009 07:14:47 +0800

> that we're talking about the updated version.
so it is SIITbis, but we can just call it SIIT.
> We may want to avoid making a version 2 of NAT64 because NAT642 would 

understood. or NAT64bis?

xing

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 02 Jun 2009 10:13:05 +0200

Rémi Després escribió:
> NAPTs, I don't believe NAT is  "commonly understood" as only stateful. 
> For example:
> - In RFC 2663, a NAT is either stateless ("Basic NAT") or stateful (NAPT)
>> for that reason, i believe that using the expression NAT64 and NAT46 
>> highlight the main difference with current NATs, i.e. that they 
>> translate IPv6 to and from IPv4 and in the case of 64 they support 
>> communications iniciated from the IPv6 side and in the case of 46 
>> they support communications initiated from the IPv4 side.
>
>> I think that the stateless translator is a very different device from 
>> the most common version of IPv4 nats, since they are stateless, so i 
>> think it makes sense to name it with a different name that highlights 
>> the fact that they are stateless. I think SIIT, stateless translator, 
>> even stateless IPv4/IPv6 translators make sense.
>>
>  As far as a stateless NAT is concerned, I share the view that SIIT is 
> more intuitive than the "Basic NAT" of RFC 2663 (especially since most 
> NATs are in fact NAPTs).
>
>  Where external and internal address families are not implicit in the 
> context, they could be indicated with a NATxy notation, with (x 
> internal, y external.
>  For example:
> If it can be accepted that stateful NAT64 is named NAPT64, we can get, 
> quite naturally IMHO:
>

imho, this is just too complex for people to use it

 From now, we are only working on stateless and statefull translation, 
so, i would limit to define names for those and i would go for SIIT and 
NAT64.

Regards, marcelo

> initiated from one side could de referred to as NATx>y, if connections 
> are only internal to external,  or NAPTx<y  if connections only 
> external to internal, so that:

---

From: Rémi Després <[email-masked]>
Date: Wed, 3 Jun 2009 09:46:29 +0200

Le 2 juin 09 à 10:13, marcelo bagnulo braun a écrit :

>> respectively those of internal and external address families. The  
>> NAT is sateless or stateful)
> From now, we are only working on stateless and statefull  
> translation, so, i would limit to define names for those and i  
> would go for SIIT and NAT64.

I see.
  Limiting so far to SIIT and *NAPT64*  would be fine as far as I am  
concerned.
(I understand that in some existing drafts have used NAT64 as meaning  
stateful only, but replacing NAT64 by NAPT64 in these documents   
should not be a big deal. On the contrary, limiting the acronym NAT  
to mean only stateful NATs  would be a change bound to create  
confusion.)

Regards,

RD

---

From: Xing Li <[email-masked]>
Date: Wed, 03 Jun 2009 19:04:50 +0800

> should not be a big deal. On the contrary, limiting the acronym NAT to 
> mean only stateful NATs  would be a change bound to create confusion.)
I think this is a very good suggestion, i.e. SIIT for the stateless and 
NAPT64 for the stateful translations, respectively.
(SIITbis and NAPT64bis are for their major upgrades).

xing

---

From: Kevin Y <[email-masked]>
Date: Sat, 27 Jun 2009 01:52:30 +0800

May I propose following new terms:

AFT        Address Family Translation for stateless & basic Iv4 & v6
protocols translation.
AFPT      Address Family & Port Translation for  AFT +  stateful management.
AFPT64   This means stateful translation initiated from IPv6.
Pro:
  a.  New terms &  new pronoucation, no conflict with old NAT, NAPT,
NAT-PT, & anything else
  b.  AFT & AFPT explain exactly what is happening. IPv4 & IPv6 address
family protocols translation !
  c.  It is short and simple,  once people read it, it is easy to remember
it and use it.
  d.  clear logical relationship between AFT and AFPT.
  e.  Address Family means the network protocols,  in C,  we already use
AF_INET and AF_INET6
 for IPv4 and IPv6 protocols.
  f.   Some people use AFT64 to replace NAT64, and acceptance is not big
problem !

Con:
  a.  First timer may not understand it.  But little explaination will clear
the concept.
  b.  it is not one syllable like NAT,  but if people get used to it, it is
no  hard to use it.

Thanks

Kevin Yin

On Wed, Jun 3, 2009 at 7:04 PM, Xing Li <[email-masked]> wrote:

>> stateful only, but replacing NAT64 by NAPT64 in these documents  should not
>> be a big deal. On the contrary, limiting the acronym NAT to mean only
>> stateful NATs  would be a change bound to create confusion.)
>>
>> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Dave Thaler <[email-masked]>
Date: Mon, 29 Jun 2009 01:13:33 +0000

AFT already stands for Authenticated Firewall Traversal:
http://www.ietf.org/proceedings/96dec/charters/aft-charter.html

-Dave

From: Kevin Y [mailto:[email-masked]]
Sent: Friday, June 26, 2009 10:53 AM
To: Xing Li
Cc: Rémi Després; Behave WG; Dan Wing; Dave Thaler
Subject: Re: [BEHAVE] interim meeting minutes - NAT64 definition

AFT        Address Family Translation for stateless & basic Iv4 & v6 protocols translation.
AFPT      Address Family & Port Translation for  AFT +  stateful management.
AFPT64   This means stateful translation initiated from IPv6.
Pro:
  a.  New terms &  new pronoucation, no conflict with old NAT, NAPT, NAT-PT, & anything else
  b.  AFT & AFPT explain exactly what is happening. IPv4 & IPv6 address family protocols translation !
  c.  It is short and simple,  once people read it, it is easy to remember it and use it.
  d.  clear logical relationship between AFT and AFPT.
  e.  Address Family means the network protocols,  in C,  we already use AF_INET and AF_INET6
 for IPv4 and IPv6 protocols.
  f.   Some people use AFT64 to replace NAT64, and acceptance is not big problem !

Con:
  a.  First timer may not understand it.  But little explaination will clear the concept.
  b.  it is not one syllable like NAT,  but if people get used to it, it is no  hard to use it.

Thanks

Kevin Yin

On Wed, Jun 3, 2009 at 7:04 PM, Xing Li <[email-masked]<mailto:[email-masked]>> wrote:

I see.
 Limiting so far to SIIT and *NAPT64*  would be fine as far as I am concerned.
(I understand that in some existing drafts have used NAT64 as meaning stateful only, but replacing NAT64 by NAPT64 in these documents  should not be a big deal. On the contrary, limiting the acronym NAT to mean only stateful NATs  would be a change bound to create confusion.)
I think this is a very good suggestion, i.e. SIIT for the stateless and NAPT64 for the stateful translations, respectively.
(SIITbis and NAPT64bis are for their major upgrades).

xing

Regards,

RD
_______________________________________________
Behave mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/behave