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

From: Bryan Ford <[email-masked]>
Date: Wed, 8 Dec 2004 14:06:42 -0800 (PST)

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: Pyda Srisuresh <[email-masked]>
Date: Wed, 8 Dec 2004 16:55:13 -0800 (PST)

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.

cheers,
suresh

--- Bryan Ford <baford@xxxxxxx> wrote:

> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 

=====

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 8 Dec 2004 22:00:09 -0800 (PST)

> scenario, even though all of the actual NAT boxes in use are just ordinary

I agree this scenario is definitely in scope but I get confused by some of
the terminology at times. Is this what RFC 2663 would call twice NAT?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 8 Dec 2004 22:24:40 -0800 (PST)

I agree that we need to cover the situation Bryan is talking about, but 
I have heard this called "cascaded NAT" or "multi-layer NAT" or some 
equivalent. To answer Cullen's question, I think twice NAT is quite 
different, as it specifically involves DNS tricks to deal with address 
collisions between two domains. See section 4.3 of rfc2663. I don't 
think we need to deal with twice NAT as defined in rfc2663; its really 
awful and not that common (AFAIK).

Thanks,
Jonathan R.
Cullen Jennings wrote:

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

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

Cullen & Jonathan,

RFC 2663 refers to twice-NAT as one that translates both end points of a
session. 

Consider the multi-stage NAT scenario (Refer section 3.3.3 of
ford-midcom-p2p-03) that illustrates hairpin/loopback translation on the second
stage NAT. Hairpin translation does involve translating both endpoints of a
session. By this argument, Bryan's reference to twice-NAT below is in line with
twice-NAT, as defined in RFC 2663. 

cheers,
suresh

=====

---

From: Bryan Ford <[email-masked]>
Date: Thu, 9 Dec 2004 09:15:51 -0800 (PST)

On Wednesday 08 December 2004 19:55, Pyda Srisuresh wrote:
> 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: Bryan Ford <[email-masked]>
Date: Thu, 9 Dec 2004 09:23:20 -0800 (PST)

On Thursday 09 December 2004 01:00, Cullen Jennings wrote:
> > 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.
>

Exactly the issue I just noticed, after reading Suresh's response to my 
earlier message. :)  What do you think?  What _should_ the hierarchical 
interconnect scenario be called?

Bryan

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Dec 2004 11:51:58 -0800 (PST)

> interconnect scenario be called?

multilayer nat deployments. Two layers is common in Asia (ISP and home). I
have seen 3 layers in cases where the ISP had a NAT, the business had one,
then a lab inside the business had a NAT.

---

From: Senthil Sivakumar <[email-masked]>
Date: Thu, 9 Dec 2004 11:52:13 -0800 (PST)

At 12:15 PM 12/9/2004 -0500, Bryan Ford wrote:
After just now looking back again at RFC2663's discussion of "Twice NAT" 
again

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

Senthil

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Dec 2004 12:03:59 -0800 (PST)

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Dec 2004 12:24:15 -0800 (PST)

Hmm...

If I take two normal linksys NAT and connect the two public sides together,
I do not get twice NAT. I think this description is of twice-NAT is greatly
over simplified.

---

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

Multi-stage NAT deployment being in scope sounds good to me. Actually, I didnt
think it was out of scope to start with. Oh, well..

regards,
suresh

=====

---

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

Senthil,

I agree with what you say. However, the multi-stage NAT scenario that Bryan
talks about exhibits twice-NAT characteristic (when suporting hairpin
translation), in that both endpoints are translated. This happens even as the
NAT box itself may not have been configured with twice-NAT address maps.

regards,
suresh

=====

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Dec 2004 13:29:27 -0800 (PST)

I don't know what multi stage is but multilayer as described in Bryan's
email has always been one of things this document wanted to work with.

---

From: Bryan Ford <[email-masked]>
Date: Thu, 9 Dec 2004 14:35:45 -0800 (PST)

On Thursday 09 December 2004 14:52, Senthil Sivakumar wrote:
> 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.

>are confused, imagine 99.999% of the world that needs to deploy this.

Hear hear.

Bryan

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 9 Dec 2004 18:11:56 -0800 (PST)

Sorry, that is what I meant.

regards,
suresh

=====

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 9 Dec 2004 18:40:46 -0800 (PST)

OK, No problem. Use of hairpin translation & multi level NAT deployments would
work for me. 

cheers,
suresh

--- Cullen Jennings <fluffy@xxxxxxxxx> wrote:

> fashion.

=====