Talk:Network address translation

Lead too long and technical

The lead is too long and contains too much technical content. This content would be better suited as being rewritten and placed in its own (or another) section. The lead should be written so that it is as less technical as possible.

The lead is messy because it is long. The lead should summarise key points in the article and provide a brief overview of what NAT is and/or does, rather than being a commentary on all the technical background.

--Hrbm14 (talk) 03:27, 5 February 2015 (UTC)

Lead is just two paragraphs today ~Kvng (talk) 18:05, 20 September 2024 (UTC)

Missing a Section for References Cited

Citations like appear in the article itself, but clicking the 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)

References

Vagueness and ambiguity...

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

Phrase no longer in article ~Kvng (talk) 18:05, 20 September 2024 (UTC)

style

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

Mostly fixed earlier. Touched up a couple of remaining issues today. ~Kvng (talk) 18:05, 20 September 2024 (UTC)

STUN

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)

The second paragraph of Network address translation#Methods of translation is clear that STUN is deprecated. Is there still an issue here? ~Kvng (talk) 18:05, 20 September 2024 (UTC)

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) bhcshffszhcvzfjhf good —Preceding unsigned comment added by 125.19.8.154 (talk) 15:35, 29 December 2010 (UTC)

Term no longer in article. ~Kvng (talk) 18:05, 20 September 2024 (UTC)

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)

See #Vagueness and ambiguity... and #STUN above for resolution of these issues. ~Kvng (talk) 18:05, 20 September 2024 (UTC)

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

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

If each of semicircles represents a port, then diagrams and descriptions contradict one another. —Preceding unsigned comment added by 91.195.22.32 (talk) 15:17, 17 February 2009 (UTC)

Agree, the diagrams should be labelled or redrawn. Thanks. — Preceding unsigned comment added by 116.199.214.34 (talk) 01:59, 30 May 2012 (UTC)

As 91.195.22.32 says, purpose of semicircles is not given, but only the ports make the sense. Then it completely doesn't correspond to explanation! Secondly, behind NAT there is more devices, but here is only one. That's confusing, it makes feeling that there's enough space for port mapping. Koko7 (talk) 11:23, 13 September 2012 (UTC)

Here are correct ASCII style diagrams. Mpb2 (talk) 01:15, 23 March 2014 (UTC)

I've added requests for improvement to the talk page of these diagrams: Commons:File talk:Full Cone NAT.svg, Commons:File talk:Restricted Cone NAT.svg, Commons:File talk:Port Restricted Cone NAT.svg, Commons:File talk:Symmetric NAT.svg. ~Kvng (talk) 18:05, 20 September 2024 (UTC)

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)

Works for me: Firefox 130.0.1, Windows 11. ~Kvng (talk) 18:05, 20 September 2024 (UTC)

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)

For now, I've added a note to Network address translation#Translation process. We could discuss this more prominently if we had a source. ~Kvng (talk) 18:05, 20 September 2024 (UTC)

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 theend-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)

Surprise: no one claims to have invented this kludge which goes against one of the founding principle of the Internet. Or maybe some patent company will in the future. Marchash (talk) 13:33, 2 October 2009 (UTC)

It is odd that no-one has claimed the honor, for this great idea of getting rid of the firewall proxies there used to be before NAT. This ridiculous attitude of calling NAT a kludge and whining about so-called founding principles of Internet is void as far as there are 70% of happy Internet users behind a NAT. Calling windshield a kludge against founding principles of insects flying into your eye does not make the invention of windshield any worse, people will continue to use it. Seikku Kaita (talk) 08:54, 21 November 2010 (UTC)

If you have public IPs on internal networks you never had to have proxies, just little holes in the firewall. You only (still) need to have an application proxy if you're doing something more involved. The necessity to proxy every single port is a direct result of using NAT. As for the users being happy ... well as long as they stay good little consumers they may be, but many games nowadays need 'ports opened' and directed to the ONE PC that can play the game. Opening ports is a minor pain, "ONE PC" will make them very unhappy. I wouldn't be surprised if games (and other apps) start to appear that require either a public IP or Teredo. 90.204.215.80 (talk) 17:36, 4 December 2010 (UTC)

I think it was invented/discussed in this post on the Firewalls Mailing List in 1992: http://www.greatcircle.com/firewalls/mhonarc/firewalls.199212/msg00089.html The terminology NAT does not appear (it didn't exist yet), but the implementation concept clearly discusses replacing address and port numbers with other addresses and ports rather than having multiple connections and a proxy process.

72.45.221.198

Interesting. Mailing list link is dead but here's an archive. ~Kvng (talk) 18:05, 20 September 2024 (UTC)

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)

NAT is NOT what provides the security in this case, and, a stateful IPv6 firewall can easily have a default deny policy for incoming sessions without the breakage caused by NAT. NAT is unnecessary except for address shortages, or, extraordinary circumstances such as a desire/need to present a network as an artificially different prefix. The breakage caused by NAT vastly exceeds its usefulness for most of the IPv6 world, and, the claims of security have been repeatedly proven to be mythical. —Preceding unsigned comment added by Owendelong (talk • contribs) 18:59, 11 September 2009 (UTC)

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

The "It has been argued that..." content is no longer in the artile. We have now some WP:NPOV statements about NAT and IPv6 in Network address translation#Issues and limitations and Network address translation#NAT in IPv6. ~Kvng (talk) 18:05, 20 September 2024 (UTC)

further expansion of a seemingly unrelated statement?

I'm left to only guess at the meaning of the following statement:

It is also a problem with Xbox Live gameplay when the need for players to communicate becomes harder and slows down gameplay.

Particularly, how does it relate to NAT? Are NAT issues what cause the slowdown? Do they hinder communication? Or does scaling the number of players upwards prove difficult due to NAT issues? But at face value, the statement seems to have little to do with NAT.

Would the author of the statement please expound further? Thanks.

--Paul (talk) 19:13, 25 June 2008 (UTC)

No longer any mention of Xbox in the article. ~Kvng (talk) 18:05, 20 September 2024 (UTC)

Self-referencing See-Alsos

Maybe it's my wikipedia-n00bdom, but I don't see much point in a see-also that goes to a redirect page that comes back to the NAT page, even if it does try to send you right to the appropriate anchor. Should those see-alsos just be removed? Kraigus (talk) 15:10, 11 September 2009 (UTC)

This often happens and goes unnoticed when articles get merged. Sometimes it's used as a placeholder when someone intends to write a new article from a section (but that often doesn't happen later). So, yes, in general they should be removed. Kbrose (talk) 15:58, 11 September 2009 (UTC)

Links checked. This was cleaned up at some point. ~Kvng (talk) 18:05, 20 September 2024 (UTC)