Subject: RE: [Ietf-behave] Twice NAT _must_ be in-scope

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Dec 2004 09:25:07 -0800 (PST)

I think we can safely not talk about Twice-NAT in the document.

I don't think it should be the job of BEHAVE to clarify the
twice-NAT terminology...

In reality being BEHAVE-compliant in a NAT always used
as a twice-AT is probably not terribly useful. However, if the
NAT is intended to be used either in Twice-NAT mode or Traditional
NAT mode, it might be worthile to be BEHAVE compliant for both.

> -----Original Message-----
> From: Bryan Ford [mailto:baford@xxxxxxx] 
> Sent: Thursday, December 09, 2004 09:16
> To: Pyda Srisuresh
> Cc: Audet, Francois [SC100:9T51:EXCH]; 'Behave'
> Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope
> 
> 
> On Wednesday 08 December 2004 19:55, Pyda Srisuresh wrote:
> > Hi Bryan,
> >
> > That is a good point you bring up. Essentialy, what you 
> area saying is 
> > that hairpin/loopback transaltion involves translating both 
> endpoints. 
> > That is the characteristic of a twice-NAT. So, we shoudl include 
> > twice-NATs in soope. I like that.
> 
> Hmmm...  It's nice that everyone agrees with me, but now I'm 
> not sure I agree 
> with myself anymore... :)
> 
> After just now looking back again at RFC2663's discussion of 
> "Twice NAT" again 
> (section 4.3), I noticed that the details of the specific 
> motivating scenario 
> discussed by the RFC is quite different than the typical 
> "Twice NAT" scenario 
> of today that results from combinations of Traditional NAT boxes on a 
> network.  RFC2663's "Twice NAT" scenario basically seems to be about 
> organizations that want to keep using old "public" IP 
> addresses on their 
> private networks that are no longer allocated to them 
> globally.  The result 
> is similar in either scenario, in that the internal and 
> external address 
> spaces may overlap arbitrarily resulting in a need to 
> translate both the 
> source and destination addresses in packets - but the 
> motivating scenarios 
> are quite different.  Also, in the way RFC2663 explains Twice 
> NAT, it _does_ 
> in that context sort of come across as "a fundamentally 
> different kind of NAT 
> box" rather than just an outcome of interconnecting multiple 
> Traditional NATs 
> in hierarchical fashion.  As per my previous message, the 
> latter form of 
> "Twice NAT" (as I've been using the term) definitely needs to 
> be in-scope for 
> BEHAVE, but the  former, strange and hopefully deprecated 
> scenario discussed 
> in RFC2663 obviously should not be.
> 
> So I'm wondering if we have a potential terminology confusion 
> issue here.  
> What do the people on this list think of in association with 
> the term "Twice 
> NAT" - do you associate the term with "multiple levels of Traditional 
> NAT" (which has so far been my natural association with the 
> term), or do you 
> associate it with "a particularly weird type of NAT box that is 
> administratively set up to translate between two 
> arbitrarily-overlapping IP 
> address spaces"?  Should we perhaps use the term "Multi-level 
> Traditional 
> NAT" or something like that to refer to the hierarchical 
> interconnection of 
> Traditional NATs, in order to avoid potential confusion with the 
> RFC2663-style "Twice NAT" scenario?  (In which case 
> Francois's original 
> paragraph about "Twice NAT" being out of scope would actually 
> be correct, and 
> we'd be inventing new terminology to cover the hierarchical 
> interconnect 
> scenario.)  I don't have a strong feeling either way on this 
> - I'm also happy 
> to keep reusing the term "Twice NAT" the way we have been, as 
> long as the 
> hierarchical interconnect scenario is included and clearly 
> explained somehow.
> 
> Cheers,
> Bryan
> 
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 9 Dec 2004 13:21:33 -0800 (PST)

--- Francois Audet <audet@xxxxxxxxxxxxxxxxxx> wrote:

> as a twice-AT is probably not terribly useful. 

[suresh] I disagree. A twice-NAT could be using NAPT type of translation for
one of the endpoints (i.e., one address multiplexing for several machines) . It
would be useful to have Behave compliance there.

>                                                However, if the

[suresh] Yup.

regards,
suresh

> > hierarchical interconnect scenario is included and clearly 

=====