Talk:Network address translation

From Wikipedia, the free encyclopedia

"Bus" network topology This article is part of WikiProject Computer networking, an attempt to build a comprehensive and detailed guide to Computer networking on Wikipedia. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
Computer networking Portal
B This article has been rated as B-Class on the assessment scale.
Mid This article is on a subject of mid priority within Computer networking for inclusion in Wikipedia 1.0.
Computer networking To-do:

Contents

[edit] Distinction between NAT and stateful firewalling

From the Benefits section of the article, it claims that "[NAT] can enhance the reliability of local systems by stopping worms and enhance privacy by discouraging scans" - this is not a function of NAT at all but a stateful firewall. NAT doesn't magically protect clients behind the LAN from receiving packets from the Internet to the private address space unless the firewall on the router rejects such packets. By the same token, a network of fully public IP space (such as a DMZ) can have the same benefit by having the router block unwanted connections from the outside based on connection state. NAT is not the same as a firewall, although it is commonly used in combination with one. I'd like to make a distinction in the article between benefits (such as load balancing, failover, and other such uses mentioned further down in the article) and perceived benefits such as the concept of a so-called 'NAT firewall'. As I look for a good reference or two to add in with my edits (feel free to suggest some if anyone has good links,) I'd like to give people who disagree a chance to say so so we can discuss why NAT isn't a firewall. A couple comments on this talk page seem to ignore this which is why I bring it up here first. Pekster (talk) 00:02, 27 May 2008 (UTC)

[edit] Missing a Section for References Cited

Citations like [1] appear in the article itself, but clicking the [2] links lead to nothing and there is no section at the bottom of the page which lists them all. I am not sure if I'm mistaken or what sort of malfunction this is but this seems to be very bad for the article! 07 08 31 —Preceding unsigned comment added by 68.144.16.61 (talk) 19:00, August 30, 2007 (UTC)

[edit] Vagueness and ambiguity...

"According to specifications, routers should not act in this way..." - which specifications? RFCs??

[edit] style

This article has a "lot" of useless "quotes" that should be "removed".

It would be nice if the note that the STUN classification had been abandoned was in the introductory paragraph of the section Different types of NAT, rather than the concluding one. Having carefully read through trying to understand, to find out it's no longer used is frustrating. Also, the diagrams in this section draw the eye first and can mislead readers into believing that these diagrams explain NAT, when in fact they only explain the outmoded classification system. DarkJMKnight 19:08, 9 February 2007 (UTC)

[edit] asynchronous nat

anyone got any references for this term. my guess is it reffers to a setup with 1:1 nat that doesn't do anything statefull at all but just changes the ips. Plugwash 02:39, 24 Jun 2005 (UTC)

[edit] mistake?

layer 3? The article says "Some higher-layer protocols (such as FTP, Quake, and SIP) send layer-3 information inside IP datagram payloads. FTP in active mode, for example, uses separate ports for control traffic (commands) and for data traffic (file transfers)." This is correct, there is the NAT/PAT problem with protocols like FTP, though port information included in FTP packets are concerning the TCP port and hence are layer-4, or did I miss something?

Clarified: Yes, the text was a bit inaccurate. Both layer 3 and layer 4 data are subject to being invalidated by passing through NAT, depending on whether port translation is also in use. I hope the text is now clearer. Mditto 01:25, 18 November 2005 (UTC)

[edit] typo in the PDF linked at the article

The external link http://list.sipfoundry.org/archive/ietf-behave/pdf00000.pdf provides a really good example but unfortunately it seems to have some mistakes in the diagram: the destination address:port D keeps the value 1.1.1.5 at the private host while it should be D=1.1.1.6 Probably a typo, but very confusing one..

I don't like the fact that an external pdf is linked in the text. --Ggonnell 17:54, 1 April 2006 (UTC)

I agree. The first person ("I would respectfully...") needs to go too. --Chris (talk) 20:22, 15 May 2006 (UTC)
I worked on that section. The whole section is so specific that it may not be appropriate for an encyclopedia article. JonHarder 22:04, 15 May 2006 (UTC)

[edit] Citations/copyright

The following statements need citations:

  • "according to specifications, routers should not act in this way": which specifications? This sentence implies that NATting is frowned upon whereas I think it's generally accepted as necessary given the limitations of IPv4 address allocation.
  • "this classification is now abandoned": I don't think this is true. It is still useful e.g. as a way for a STUN client to tell an application about the network it's on.

Also, the majority of the text of classification section is taken directly from RFC 3489.

Daf 16:00, 16 September 2006 (UTC)

[edit] NAT and security

Some note could/should be added about NAT not bringing any security contrary to popular belief ýThe preceding unsigned comment was added by 130.233.243.229 (talk) 07:47, 11 December 2006 (UTC).

NAT add security. Common NAT are very similar to restrictive inbound firewall. In the home usage (without servers) it avoid external connection to any local machine, so user can be "infected" only by going into wrong hosts/sites (malice, ignorance, spoofing, cross scripts,...). So it is one security measure. Cate | Talk 09:47, 11 December 2006 (UTC)

I think this also applies in the IPV6 case. The statement that NAT isn't useful in connection with IPV6 ignores the natural firewall provided by a default SNAT router configuration installed by a consumer ignorant of how to configure firewall rules (unless we know that all consumer grade IPV6 routers will block incoming server connections by default which seems very unlikely).Copsewood 19 Jan 07

Add "Hairpins and Determinism" Hairpin operation - a local host directs a packet to the public address and port of an already mapped local host and to its own mapped address and port. The NAT bindings are available to either side of the NAT

Nondeterministic NATs change their binding behavior when there is a binding conflict. Some NATs attempt to preserve the port address in the binding, so that the local source port and the externally bound port are the same whenever possible. If another local host obtains a NAT binding using the same source port number, then the behavior of the NAT for this conflicting port binding may differ from that where the port number is preserved. In some cases the behavior of NAT for the first connection is that of a full cone, or a restricted cone, while the NAT behaves in a symmetric fashion for the secondary instance where the port number has been mapped to a new value by the NAT.

It is also possible that the NAT may elect to preserve the binding in any case, and remove the current binding and replace it with a new binding that refers to the most recent packet that the NAT has processed.

All these behaviors can be classified as nondeterministic, in that the NAT behavior becomes one that is determined by the order of outbound traffic.

Port preservation, Port overloading, Port multiplexing Binding Timer Refresh: Bidirectional, Outbound, Inbound, Transport Protocol state Larytet

[edit] NAT as network administration tool

I think not only NAT as security tool should be mentioned, as requested above, but using NAT as admin tool is also missing.

I think, "NAT because of IP address shortage" is just ONE single exceptional application (of course, this one application is used in millions of installations behind dialups and alike).

For instance, it might be helpful when upgrading servers without letting clients taking notice or adding "compatiblity modes" when moving / restructuring networks. If for instance, the IPs of a subnet are changed, for a while NAT can be applied to catch missconfigurations without disturbing users. Admins can monitor log files / IDS to detect and fix this, finally removing NAT when everthing is tested and working.

Even when linking some home private networks via VPN or so, NAT may help (192.168.1.0/24 is widely used :-)).

-- Steffen http://de.wikipedia.org/wiki/User:STD

[edit] Unclear Types-of-NAT Diagrams

As a NAT novice, I have been unable to work out which side is internal and which is external. This information needs to be added to each diagram (or at least a note at the section beginning) ýThe preceding unsigned comment was added by Dorcots (talk " contribs) 08:23, 6 February 2007 (UTC).

[edit] Unprintable diagrams?

I tried printing a couple of different ways, but the "Different types of NAT" diagrams come out with a solid black background. Is there something that can be changed to make them display right universally? DKEdwards 22:35, 19 June 2007 (UTC)

[edit] Origins

The most common form of NAT today is one-many (ie one to many) NAT. I remember many-many NAT being around by 1994 in (IIRC) Solaris but the first one-many NAT I know of was the "IP Masquerade" code under Linux, first introducted in the 1.1 kernel IIRC. I've RTFMed on this in the past and have not found a definitive answer. Did anyone implement one-many NAT before the Linux IP Masquerade authors around 1994-1995? If we can get a bit of history on the origins of one-many and many-many it would be a good addition to the article. Robert Brockway 22:21, 15 February 2007 (UTC)

[edit] Missing Drawback: Port Shortage?

While this problem rarely occurs, it can reach serious dimensions, including total denial of service for internet conections from a private network - and it is real.

As the NAT router reserves allocates an individual port for each outgoing connection, a huge number of outgoing connection may saturate the range of available ports. As ports typically get freed when the connection doesn't produce any more traffic for a certain time (TTL, ot "time to live"), the maximum number of connection is limited to approximately to 64K/TTL.

Not an issue in most cases, I agree. However, there are two possible situations worth mentioning:

1. the LAN has a real large number of machines which open connections to the internet,

2. one machine in the LAN opens an abundance of connections to the internet.

In case 2, a single machine may be sufficient to cause denial of service. Note that case 2 will most likely be caused by some faulty software, but it may still disable the complete internet access of a company (until the tech guys find out what's going on...).

I experienced case 2 a few times arleady. Most unpleasant situation, I might add.

Maybe someone with somehow more insight than me could cast this into reasonable words to suit the article? TIA! --80.134.62.42 20:51, 13 May 2007 (UTC)

[edit] Who invented NAT?

And where did it come from? Bilge [TC] 14:14, 24 May 2007 (UTC)

I don't think there is consensus over this subject. As far as I understand, there's is not a single RFC or Internet-Draft defining a NAT. Don't get me wrong, there is a number of RFCs and I-Ds that discuss the already deployed "legacy" NATs, their individual behaviors and effect on the Internet - especially their negative effect of the NATs on the end-to-end principle. These documents, however, have emerged after NATs have been deployed. During the past decade or so, Network Address Translators have become popular as a way to deal with the public IPv4 address shortage. Thus the NATing property has just been embedded to routers as a quick cure. There was probably no discussion on what would be the effects on the Internet as a whole. I suppose it was all ok for the deployers of NATing routers just as long as the company behind the NAT would get enough computers connected to the Internet with minimal financial efforts. To answer your question: no one knows. --Siipikarja ♫ 13:31, 25 February 2008 (UTC)

[edit] NAT as a firewall (as in NAT-router or NAT-modem)

Can there be more said about NAT in the context of consumer-grade (residential or SOHO) routers or broadband modems with built-in NAT functionality. Specifically, given that class of hardware, can it be said that the in-bound firewall effect of NAT is equivalent to (if not superior to) software firewalls running on a client machine (and again I'm comparing the in-bound firewall effectiveness of the NAT-router or NAT-modem vs the inbound direction of the software firewall).

Many people seem to think that NAT makes a poor in-bound firewall compared to a sofware firewall. Are they right? What is the argument for or against such a belief?

NAT proper is mostly security by obscurity. Adding inbound rate limiting against brute force attacks, and doing stateful firewalling add greatly to the protection. As it is, I write my own firewall rules, and I still use host-level firewalling, and have backups and such on a physically separate house network separated from the Internet gateway. Howard C. Berkowitz 03:54, 3 July 2007 (UTC)

"NAT proper is mostly security by obscurity". While that may be a cute phrase, technically that isin't correct. NAT works by keeping a table of out-bound and in-bound packets (ie - port assignments) and simply drops incoming packets that don't have a matching out-bound table entry that was assigned by the router itself.

"Security by obscurity" is a very serious phrase that describes a lot of user behavior that really doesn't provide much security.
Strictly speaking, you are describing a special case of NATP (network and port translation). There can be legitimate cases where there is no clean match from an outside source/port to an inbound address/port, due to issues such as redirection (e.g., in HTTP or FTP). This sort of thing needs a true application layer gateway or highly intelligent stateful proxy, not just NAT, to determine if traffic is legitimate. Howard C. Berkowitz 19:01, 14 July 2007 (UTC)

I guess my question boils down to, say, the difference between NAT as a firewall vs Stateful Packet Inspection from a security point of view. Or, what is the difference between a NAT router vs a software firewall when we are considering in-bound malicious activity.

This depends, in part, of your definition of a firewall. To me, a firewall is often a proxy, and at least stateful, in examining inbound traffic. Every environment has to be evaluated. Is it plausible that a hostile individual can hijack TCP sessions and exploit the known sessions. Stateless NAT is pretty limited as a security tool. I'd rather not see much security discussion in that article, with the security part being in a firewall article. Howard C. Berkowitz 19:01, 14 July 2007 (UTC)

Ok, let me ask this. The main article defines "Symetric NAT" under "Different types of NAT". I believe that it should also call it "one to many" in the same way that "Full Cone NAT" is AKA "one to one". Given symetric NAT (one to many), are external unsolicted in-bound packets (both UDP and TCP) blocked or dropped, or just TCP?

Can it be said that a "symetric NAT-router" blocks or drops all external in-bound unsolicited packets, regardless of the type of packet?

And can it also be said that a typical home or SOHO NAT-router is a "symetric NAT-router" ?

When it comes to unsolicited in-bound connection attempts, does a software firewall application have any capabilities to provide extra "protection" that is not performed by a SOHO NAT-router?

When it comes to SOLICITED in-bound connection attempts, must a software firewall application employ Stateful Packet Inspection in order to provide some level of security or monitoring of those packets - and how many firewall programs perform this inspection?

(I am trying to get an answer as to what redeeming utility a software firewall has when it comes to in-bound connections or in-bound data monitoring that isin't already performed by a NAT-router. That is why this section is called "NAT as a firewall").

[edit] NAT behavior article needed

Folks, we need a NAT behavior article describing (at least) the endpoint mapping and endpoint filtering characteristics. Other stuff that is included in RFC 4787 would be nice, diagrams illustrating the behavior would definitely be a plus. The RFC is all about UDP, but the same properties apply for TCP and others also. --Siipikarja 19:13, 29 August 2007 (UTC)

[edit] NAT vs PAT

Trying to keep this brief - 2 main strands:
1. NAT and PAT are very different. I guess no disagreement there. Secondly while most people talk about NAT they usually mean PAT. Again I guess we agree here. The DIFFERENCE comes in that I think we should state that just calling PAT, NAT is incorrect. I want this stated clearly hence my edit. 2. Though possibly overlooked, I also tried, very briefly and I accept probably inadequately, to show that there are a number of different types of NAT. The two most common are static NAT and 'pooled' NAT. I hope this is non-contentious, though I accept I've not made this very clear but then in an introductory section I didn't think a detailed discussion was required. I hope this makes clear what I am trying to achieve. Mercury543210 19:43, 1 October 2007 (UTC)

PAT is indeed the predominant technique, if for no other reason than the need to recompute TCP and UDP checksums. True NAT, however, can apply to IP-only things such as ICMP. Howard C. Berkowitz 19:54, 1 October 2007 (UTC)
Where did this term PAT come from in the first place? It seems the RFCs use basic nat to reffer to things that only translate IPs, NAPT to things that translate both and NAT as a general term covering both. I think we can take the terminology the RFCs use as authoritive. Plugwash 23:03, 1 October 2007 (UTC)
I do remember, at some IETF meetings, someone trying to say NAPT, and the appropriate protocol response seemed to be Gesundheit! Howard C. Berkowitz 00:32, 2 October 2007 (UTC)
Hmm I have no problems saying it........... Plugwash 13:22, 2 October 2007 (UTC)

A quick google for 'NAPT firewall', throws up about 281k hits, 'PAT firewall' returns over 1.7 million hits. Since an encyclopaedia should be accessible, can I suggest that we stick with the more common term PAT and not RFC 3022's NAPT? Mercury543210 20:08, 2 October 2007 (UTC)

PAT vs NAPT
  • Neither term is common
  • PAT is misleading (devices that change the port number almost invariablly change the IP address as well)
  • NAPT is what the RFCs use
  • Looking at your google results it seems that PAT is a term mostly used by cisco and its community and isn't in widespread use outside of that.
Afaict the terms PAT and NAPT appear together once in the article (there is also a see also to a seperate PAT article but that should probablly be merged here it mostly duplicates information from this article anyway). I don't see any pressing need to use them elsewhere in the article.
Your point is? An encyclopaedia is about accessibility, if the majority use PAT then that is the term most people, if not techies, will come across and we should use it. You could then inform them that the official term is NAPT but it's not one they would have come across. Also this seems an odd argument as currently the section title does not use NAPT anyway, so what are you saying?
PS please sign your comments. Mercury543210 16:48, 3 October 2007 (UTC)
My point is I don't think there is any need to push either of the terms neither of which is in common use. Plugwash 16:52, 3 October 2007 (UTC)
I agree NAPT is not 'in common use' - that is the point I'm making. It is also quite clear that PAT is 'in common use'. Hence my concern that we are following a line which excludes non-specialists from finding and learning. I still think we should use common terms, even if they're disliked (why?) by some. Mercury543210 18:40, 4 October 2007 (UTC)
As an informative article, whether it's in common use or not should be moot. By not clarifying which one, it can generate confusion as to which one is correct. I think the emphasis of the section, however, should be the behavior of the protocol; controversy over it's name is probably another article altogether. Perhaps simply explaining the correct term NAPT according to RFC 3022 (with linked reference of course,) but it is commonly called PAT for reasons lost to obscurity would sufficient address both Mercury543210 and Plugwash's concerns? Undisputedloser (talk) 16:55, 6 December 2007 (UTC)

[edit] Inappropriate argument about IPv6's making NATs useless

It has been argued that the wide adoption of IPv6 would make NAT useless, as the latter is a method of handling the shortage of IPv4 address space. However, this argument either ignores the natural firewall provided by NAT, or assumes that consumer-grade network routing devices (which are often installed by purchasers lacking knowledge of firewall configuration) would always be factory configured to block incoming server requests.

Why would anyone want this type of "firewall"? This is exactly what is wrong with NATs. If a computer doesn't want to accept an incomeing server request *it shouldn't be listing on that port*! A computer accepts these requests voluntarily, unless a virus has infected the computer in the first place. I'm going to trim this paragraph to not imply that this is a good thing. Fresheneesz (talk) 06:26, 21 November 2007 (UTC)

You might be mistaken here - it is a rather simple firewall functionality - still - a host would be exposed to any kind of DOS attack from the outside without even a simple NAT mechanism that prevents such connections. Maybe the inside host is listening to connections from other inside hosts? (Yes there are client firewalls - so why buy ASAs, Checkpoints or Netscreens anyway?) I disagree with your trimming - so it is a 'good thing' in my opinion .. CiscoKid-728 4th December 2007 —Preceding comment was added at 19:14, 4 December 2007 (UTC)


Hello —Preceding unsigned comment added by 86.147.121.74 (talk) 20:03, 15 February 2008 (UTC)

[edit] PAT popularly, but incorrectly, called simply "NAT"

PAT (Port Address Translation) - The type popularly, but incorrectly, called simply "NAT"

I thought I knew what NAT was, then I came to this page. Ok, so according to the article, PAT is the mechanism by which multiple machines share a single IP address. All the home routers I've ever used have called it NAT. But why is it incorrect for PAT to be called NAT? The article states that there are two kinds of NAT: PAT and Basic NAT. Therefore PAT should come under the umbrella term of NAT. Secondly the article itself uses NAT to mean PAT:

NAT first became popular as a way to deal with the IPv4 address shortage

This clearly refers to PAT because with Basic NAT there is a 1:1 correspondence between external IP addresses and internal IP addresses, and that doesn't give you any extra addresses at all. Egriffin (talk) 12:12, 25 February 2008 (UTC)