Subject: [v6ops] double nat

From: Randy Bush <[email-masked]>
Date: Tue, 02 Oct 2012 11:13:24 +0100

so, is double nat really worse than single nat?  is it formally
different?  except in the case of overlapping spaces, of course.

draft-donley-nat444-impacts-04.txt seems to back off reports of
application issues.  anyone care to swing the clue by four as to
where multiple layers of nat are formally worse than one layer?

randy

---

From: "Arkadiusz Kaliwoda (akaliwod)" <[email-masked]>
Date: Tue, 2 Oct 2012 10:26:07 +0000

so, is double nat really worse than single nat?  is it formally different?  except in the case of overlapping spaces, of course.

draft-donley-nat444-impacts-04.txt seems to back off reports of application issues.  anyone care to swing the clue by four as to where multiple layers of nat are formally worse than one layer?

[Kali] IMHO it is not only important how many NAT layers exist but where NAT is implemented. DS-Lite is technically speaking NAT44 and it is no better or worse imho from the NAT444; simply because in case of DS-Lite, NAT44 is not where it should i.e. not at the home gateway. Then we move NAT44 back to the home gateway, while keeping IPv6 transport, with MAP-E/T, and we have yet another characteristics of NAT impact. 

Kali

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 02 Oct 2012 12:17:49 +0100

> different?  except in the case of overlapping spaces, of course.

it's twice as secure, yo.  Any questions?

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 02 Oct 2012 12:24:13 +0100

> where multiple layers of nat are formally worse than one layer?

on a slightly less facetious note, you will run into the problem that your
feature set will be reduced to the lowest common denominator feature set of
all the nat implementations on your network path + some delta breakage.
For many services this probably won't make a whole pile of difference, but
for protocols which require ALG support, you can run into difficulties
either through implementation or policy.  E.g. PASV followed by no PASV for
ftp, broken sip implementations, etc.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 2 Oct 2012 13:43:40 +0200

> different?  except in the case of overlapping spaces, of course.

AIUI, double NAT requires you to use PCP if you want to open ports. If you
only have one NAT, you can get by with UPNP, which while not particularly
pretty is at least currently implemented.

---

From: "Arkadiusz Kaliwoda (akaliwod)" <[email-masked]>
Date: Tue, 2 Oct 2012 11:49:22 +0000

AIUI, double NAT requires you to use PCP if you want to open ports. If you only have one NAT, you can get by with UPNP, which while not particularly pretty is at least currently implemented.

[Kali] When you move single NAT to the edge device, DS-Lite, PCP is also needed. Again, it is equally important where NAT is, not only how many NAT layers we have. Then UPnP dependency problem is also popping up since state of UPnP IGD:2 support on both commercial gateways and applications is questionable.

---

From: Gert Doering <[email-masked]>
Date: Tue, 2 Oct 2012 13:54:21 +0200

Hi,

> where multiple layers of nat are formally worse than one layer?

One of the problems with "someone else controls your NAT" is that
you can't add port mappings.  This seems to be an inevitable side 
effect of NAT444 (but can happen with single NAT44 as well, of course,
depending on where it's placed).

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Oct 2012 13:27:18 +0100

> where multiple layers of nat are formally worse than one layer?

If you think the referrals problem is serious, multiple NAT makes it
worse by creating additional addressing realms.

The probability of losing a session due to NAT state loss is presumably
greater when there are more NATs on the path.

   Brian

---

From: Jared Mauch <[email-masked]>
Date: Tue, 2 Oct 2012 08:42:04 -0400

For users: 

Only in the case of inbound traffic. The only devices that I am aware of this majorly breaks is the Xbox 360. These also break when more than one is out there as well.

I'm sure there are others but for 98% of users it just looks like the intertubes to them.

Now for the admins they need to worry about state and other resource exhaustion, but that's the case with single nat as well.

- Jared

---

From: Ivan Pepelnjak <[email-masked]>
Date: Tue, 02 Oct 2012 14:44:22 +0200

I always wondered how P2P applications react when forced to deal with 
multiple addressing realms. Example: one host sits behind CGN and 
another one behind the same CGN and a CPE NAT. Will we get hairpinning 
through outside NAT (= CGN)?

Any real-life experience with such a monstrosity?
Ivan

On 10/2/12 2:27 PM, Brian E Carpenter wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Oct 2012 13:54:52 +0100

> effect of NAT444 (but can happen with single NAT44 as well, of
> course, depending on where it's placed).

i asked *formally*.  i am not concerned with all the ops, social,
stuff.  and not about issues not directly connected to the nat.
what does double translation do that single does not?

randy

---

From: Martin Millnert <[email-masked]>
Date: Tue, 02 Oct 2012 15:13:50 +0200

> what does double translation do that single does not?

Formally, adds two translation tables while single NAT adds one.

/M

---

From: Gert Doering <[email-masked]>
Date: Tue, 2 Oct 2012 15:14:02 +0200

Hi,

> what does double translation do that single does not?

OK, sorry, I misunderstood.  

Just focusing on the technical aspects, I'd say a double-NAT doesn't do 
anything different than a single NAT.

This is assuming

 - identical implementations (like FTP ALGs that handle the same subset
   of PORT/PASV features, not different subsets in both NATs)
 - no shortage of port space on the second NAT (which is again one of
   the "real deployment" issues, not a pure theoretical "put two NAT
   boxes behind each other, without adding extra users" issue)

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Oct 2012 19:00:14 +0100

> anything different than a single NAT.

I don't see how to separate the "formal" impact of NAT from environmental
issues such as placement of middleboxes. If the traffic passes through some
kind of upper-layer-aware middlebox in between the two NATs, I am sure the
e2e result will be different than if the middlebox is at one side or the
other of both NATs, assuming the middlebox messes with the IP header or
packet size, or causes fragmentation. I doubt if there is any general
statement to be made beyond that, due the variety of NAT behaviours and
middlebox behaviours.

I think that means that there isn't a guaranteed formal equivalence
between the operation NAT() and the operation NAT(NAT()), because
in the real world we might have NAT(MIDDLEBOX(NAT())).

Another point is that geolocation will find the nearest NAT, and so will
forensic traceback.

Observational data: http://tools.ietf.org/html/draft-donley-nat444-impacts-05

>    boxes behind each other, without adding extra users" issue)

Right, making a few false assumptions does simplify mathematics ;-)

   Brian

---

From: Andrew Anchev <[email-masked]>
Date: Tue, 2 Oct 2012 18:37:49 +0000

Is this the issue you are referring to?

[Description: cid:[email-masked]]

This was corrected last December when Microsoft pushed out their latest OS update to all of their users.

Andy Anchev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jared Mauch
Sent: Tuesday, October 02, 2012 5:42 AM
To: Randy Bush
Cc: IETF v6ops list
Subject: Re: [v6ops] double nat

For users:

- Jared

v6ops mailing list

[email-masked]<mailto:[email-masked]>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Oct 2012 16:28:39 -0400

> what does double translation do that single does not?

I don't think anything…

W

---

From: joel jaeggli <[email-masked]>
Date: Tue, 02 Oct 2012 13:35:36 -0700

>> what does double translation do that single does not?
It Instantiates state in two locations. That's inherently more fragile 
than doing it in one.

---

From: John Mann <[email-masked]>
Date: Wed, 3 Oct 2012 07:42:30 +1000

Hi,

> what does double translation do that single does not?

Thinking in terms of full cone / port-restricted / address-restricted /
symmetric NAT,
does two layers of NAT using different NAT types restrict the overall NAT
class?

If the outer NAT is symmetric, I think that nullifies the full-cone or
"DMZ" settings of an inside NAT.

Does port-restricted inner NAT plus address-restricted outer NAT act like a
single symmetric NAT?

Thanks,
    John

---

From: james woodyatt <[email-masked]>
Date: Tue, 02 Oct 2012 15:39:03 -0700

On Oct 2, 2012, at 03:13 , Randy Bush <[email-masked]> wrote:
> 
> so, is double nat really worse than single nat?  is it formally different?

Yes.

> except in the case of overlapping spaces, of course.

That's the obvious case where NAT444 causes formal problems.

Another subtle formal problem arises with UNSAF systems attempting to fix the addresses of lower NAT gateways within the same upper NAT private realm.

A yet more subtle problem is NAT behavior discovery in the presence of heterogenous strategies for mapping, filtering and garbage state collection.

Finally, there is problem that I-D.ietf-pcp-base is intended to address.  Implementing a forwarding proxy service for PCP entails mapping all flows between lower NAT gateways through state in the upper NAT gateway.

--
james woodyatt <[email-masked]>
core os networking

---

From: Sander Steffann <[email-masked]>
Date: Wed, 3 Oct 2012 00:39:16 +0200

Hi,

> Thinking in terms of full cone / port-restricted / address-restricted / symmetric NAT,
> does two layers of NAT using different NAT types restrict the overall NAT class?
> 
> If the outer NAT is symmetric, I think that nullifies the full-cone or "DMZ" settings of an inside NAT.
> 
> Does port-restricted inner NAT plus address-restricted outer NAT act like a single symmetric NAT?

Hmmm. Interesting questions.
Sander

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Oct 2012 09:10:48 -0400

> like a single symmetric NAT?

Since RFC3489 we have learned that there are many more NAT 
characterization axes than just "full cone / port-restricted / 
address-restricted / symmetric". In fact, unless the two layers of NAT 
are exactly the same model, they're going to have different behaviour. 
This means that it will assuredly be harder for an application to do NAT 
traversal on two layers than on just one.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Mark Townsley <[email-masked]>
Date: Wed, 3 Oct 2012 18:06:30 +0200

30 levels of NAT for your viewing pleasure:

http://www.youtube.com/watch?v=BrlwzZZp8tM

- Mark

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 03 Oct 2012 17:54:06 +0100

> http://www.youtube.com/watch?v=BrlwzZZp8tM

But strangely unsatisfying because it was the same config on the same boxes
with the same software.  30 levels of nat, each on a different box - well
that would be a whole new playing field.

Nick

---

From: Ray Hunter <[email-masked]>
Date: Wed, 03 Oct 2012 19:13:19 +0200

AFAIK NAT assumes a single default outbound route and a return route via 
a single NAT box, and therefore stacking NAT boxes imposes use of a 
particular network topology (inverted tree with a root at the "top" NAT 
closest to the Internet GUA core). I think that's quite a significant 
formal difference than a single layer of NAT at the customer premises 
edge of a fully meshed core. Try doing inter-continental or 
multi-provider stateful failover without losing sessions (which you 
could easily do with BGP).

Also how are you going to support any protocols that require source 
routing/RSVP et al path information if the next hop or last hop is not a 
GUA?

In the single NAT case, the outside NAT address was always formally 
assumed to be a GUA, whereas the inside interface might have been an 
RFC1918 range or a GUA. Again I think that's significant from an 
architecture point of view, as even if there was an RFC1918 address in 
the path, it was easily resolvable by the local router processing that 
portion of the path to be unique (and always routed via the "inside" 
interface). Now you could have 2 RFC1918 addresses adjacent to each 
other on the path, and not know whether they were "inside" or "outside."

regards,
RayH

Warren Kumari wrote:
> On Oct 2, 2012, at 8:54 AM, Randy Bush<[email-masked]>  wrote:
>

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 3 Oct 2012 12:52:15 -0700

> Randy Bush wrote:
> > One of the problems with "someone else controls your NAT" is that you
> > can't add port mappings.  This seems to be an inevitable side effect
> > of NAT444 (but can happen with single NAT44 as well, of course,
> i asked *formally*.  i am not concerned with all the ops, social, stuff.
and not
> about issues not directly connected to the nat.

At the IP header manipulation layer, nothing. At the context layer, it
increases the potential for address realm collision, and as others have
noted the potential for differing nat models. 

You say you are not concerned about the ops stuff, but the biggest issue
related to N-layers of nat is who operates each. As long as they are all
operated by the same entity, it is an engineering problem to get all the
apps to work. Once you get more than one entity operating the path, it
becomes a contracting and legal problem to get the appropriate ports mapped.

I lost count  of the number of times people told me I didn't understand nat
when I was editing RFC 2993, but that text was actually submitted through a
double layer of nat because the carrier provided one had a limitation of 1
downstream mac. The reason the carrier device did nat was so they could use
the public address to manage it and avoid having 2 addresses on the box. The
reason it only allowed one downstream mac was that they did not believe
networks in the home were viable.

Tony

---

From: Michael Newbery <[email-masked]>
Date: Thu, 4 Oct 2012 13:31:13 +1300

> what does double translation do that single does not?

You may not be able to completely divorce them though. In the event that you are legally obligated to maintain an accurate mapping between endpoint address and public address---for instance for copyright disputes---then you now have to maintain two (or generally, n) audit logs, and you have to ensure that they match, such as when the host requests a new address. And you need to be able to correlate them so as to be able to answer the question "who did (address,port) belong to during [t1, t2]?"

If the two NATs are geographically distant, such that the speed of light is an issue, then you have introduced a degree of fuzziness into the mix. Now, there are simple techniques to work around this---but the point is that you only need to work around them because of the existence of more than one NAT.

---

From: Nejc Škoberne <[email-masked]>
Date: Sun, 28 Oct 2012 00:22:13 +0100

Hi,

I am reviving this thread, as (AFAIK) nobody mentioned the following issue:

"Other aspects of NAT behaviour, notably the NAT binding lifetime and 
the form of NAT
"cone behaviour" for UDP take on the more the more restrictive of the 
two NATs in sequence.
The binding times are potentially problematical in that the two NATs are 
not synchronised in
terms of binding behaviour. If the CGN has a shorter binding time, it is 
possible for the CGN to
misdirect packets and cause application level hang ups. However this is 
not overly different to
a single level NAT environment where aggressively short NAT binding 
times will also run the
risk of causing application level hang ups when the NAT drops the 
binding for a active session
that has been quiet for an extended period of time."

(Geoff Huston, 
http://www.potaroo.net/ispcol/2011-03/transtools-part2.pdf, page 7)

So binding lifetime desynch can be quite harmful here? Any real-world 
experience on this?

Thanks,
Nejc

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 29 Oct 2012 08:49:10 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Nejc Škoberne
> Sent: Saturday, October 27, 2012 4:22 PM
> To: [email-masked]
> the form of NAT "cone behaviour" for UDP take on the more the more
> restrictive of the two NATs in sequence.
> not synchronised in terms of binding behaviour. If the CGN has a shorter
> binding time, it is possible for the CGN to misdirect packets and cause
> application level hang ups. However this is not overly different to a
> single level NAT environment where aggressively short NAT binding times
> will also run the risk of causing application level hang ups when the
> NAT drops the binding for a active session that has been quiet for an
> extended period of time."
> 
> (Geoff Huston,

This question is probably better answered in BEHAVE, which I CC'd.

Yes, short binding lifetimes can cause applications to fail.  Consider,
for example, an application lets its connection sit idle and the
NAT clobbers the connection, and then re-uses that same IP address
and port for another (fresh) connection.  Eventually the application
using the old connection will send data.  Depending on if this was
TCP or UDP, and if it was the device behind the NAT or on the
Internet, all sorts of things could happen.

As Geoff wrote, this occurs with one NAT, if that NAT times out a
mapping before the hosts delete their mappings.

Yes, this happens in the wild.  But it is seldom diagnosed because 
it is difficult to recreate.

-d