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

From: "Francois Audet" <[email-masked]>
Date: Wed, 8 Dec 2004 14:17:48 -0800 (PST)

I see your point, and I agree. I will make the change.

> -----Original Message-----
> From: Bryan Ford [mailto:baford@xxxxxxx] 
> Sent: Wednesday, December 08, 2004 14:07
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Behave'
> Subject: Twice NAT _must_ be in-scope
> 
> 
> Hi Francois,
> 
> A comment on draft-ietf-behave-nat-00 (and apologies in 
> advanced if this issue 
> has been discussed before but I missed it...):
> 
> >   This specification only covers Traditional NATs [4].  
> Bi-directional,
> >   Twice NAT, and Multihomed NAT [3] are outside the scope of this
> >   document.
> 
> I do not think it is acceptable for us to leave Twice NAT 
> outside the scope of 
> this document (or any other BEHAVE document), because Twice 
> NAT is not a 
> distinct "type" of NAT per se, but merely a kind of _network 
> configuration_ 
> that can and does arise naturally as a result of multiple _ordinary_ 
> Traditional NATs being combined on the Internet in a 
> hierarchical fashion.  
> For example, consider the standard scenario: an ISP gets a 
> few public IP 
> addresses from its upstream provider, and uses Traditional 
> NAT to create lots 
> of private IP addresses for its customers.  Many of the ISP's 
> customers, 
> then, **independently and of their own volition**, deploy their own 
> Traditional NATs to create home networks.  We now have a 
> Twice NAT network 
> scenario, even though all of the actual NAT boxes in use are 
> just ordinary 
> Traditional NATs.
> 
> If one of the basic purposes of BEHAVE is to make the use of 
> NATs more robust 
> and deterministic, then this absolutely has to include making 
> them work in 
> all of the common, natural interconnection scenarios, 
> including Twice NAT.  I 
> think it is right for us to leave the more "exotic" types of 
> NATs out of 
> scope for now, such as bidirectional and multihomed NATs, 
> because those are 
> specific types of NAT _boxes_ that operate substantially 
> differently from 
> "Traditional NAT" boxes and often serve somewhat different 
> purposes.  It is 
> not legitimate for us to leave Twice NAT out of the picture, 
> however, because 
> Twice NAT arises from natural combinations of standard 
> Traditional NAT boxes 
> on real networks.
> 
> Cheers,
> Bryan
> 
>

---

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

Again, I'll remove the statement about Twice-NAT and static NAT.

> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Bryan Ford
> Sent: Thursday, December 09, 2004 14:36
> To: Senthil Sivakumar
> Cc: 'Behave'
> Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope
> 
> 
> On Thursday 09 December 2004 14:52, Senthil Sivakumar wrote:
> > Any time both the source and the destination addresses are 
> translated 
> > by the same NAT box, we refer to them as twice NAT. The reason some 
> > one has to translate both the source and the destination is 
> that they 
> > have overlapping networks (mostly caused by 
> mergers/acquisitions/bad 
> > design/whatever).
> >
> > But the multiple levels of traditional NATs don't cause the 
> source and 
> > destination to be translated by the same NAT box but by 
> different NAT 
> > boxes, as I see it. To me, that is not the same as twice NAT.
> 
> Multiple levels of traditional NATs _must_, in some network 
> interconnect 
> scenarios, translate both the source and destination 
> addresses in order to 
> enable reliable P2P connectivity between any two nodes.  This 
> is precisely 
> the hairpin translation issue that Suresh alluded to and was 
> discussed in our 
> original draft and elsewhere.  In this respect, multiple 
> levels of NAT _do_ 
> qualify as "Twice NAT" in this loose sense of the term as you 
> use it (and as 
> I've inadvertently been using it).
> 
> But Cullen and others have a legitimate point that RFC 2663's 
> use of the term 
> appears more restricted to a particular type of 
> special-purpose box that 
> _always_ translates both source and destination addresses 
> regardless of the 
> network configuration it is deployed in.  So I'm quite happy 
> to go with a 
> different term such as "Multi-level NAT" to refer to the 
> "hierarchical 
> interconnection of Traditional NATs" scenario in which 
> translation of both 
> source and destination ports is _sometimes_ required (in the 
> hairpin case) 
> depending on who is talking to whom.
> 
> As Cullen pointed out:
> >On 12/9/04 9:15 AM, "Bryan Ford" <baford@xxxxxxx> wrote:
> >> So I'm wondering if we have a potential terminology 
> confusion issue 
> >> here.
> >
> >I think we have proven beyond any shadow of a doubt that 
> this is true. 
> >If we are confused, imagine 99.999% of the world that needs 
> to deploy 
> >this.
> 
> Hear hear.
> 
> Bryan
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>