Talk:Network address translation/Archive 1

Archive 1

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)

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

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

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)

I agree that NAT on its own cannot act in the way you quoted. In a home or end-user network, NAT is almost universally provided by a firewall; but there is no reason why this has to be the case, and in large networks it is not uncommon to see NAT being used where no other operations are involved. You can only have the common "NAT firewall" with some level of stateful inspection, and the simplest version of this is often the home DSL router, which blocks all incoming traffic, unless it is a reply to an outgoing NATted connection; and generally with only one external IP address that's not just NAT, it's probably PNAT (a lot of users have only one device connected to their routers, in which case they don't need PNAT, but it's usually possible to connect multiple devices to the private side, in which case of course, PNAT is required). YojimboSan (talk) 08:25, 22 June 2008 (UTC)

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)

I have just removed the "but incorrectly". If someone wants to call it incorrect they had better provide a damn good cite for what you consider correct terminology. The RFCs I have seen use the term "Basic NAT" for nats that only translate IP addresses, "NAPT" for ones that translate both. They use the term NAT as a general term covering both. They do not use the term PAT at all. Plugwash (talk) 01:29, 26 June 2008 (UTC)

From a quick google test I get the impression that PAT may be a cisco-ism but i'm not sure. Plugwash (talk) 01:29, 26 June 2008 (UTC)

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)

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

Lets see, a google search for "pat nat" (without quotes. searching for pat alone would obviously bring a huge false positive rate). gets me "about 330,000" results. Searching for "napt nat" gives "about 255,000" results. By comparison searching for "nat network" gives "about 3,270,000". So it seems to me that the term PAT is a bit more common than NAPT but neither is in common use. Also of the NAT PAT results on the first page a significant proportion seem to be cisco related suggesting that this term is something of a ciscoism.

As I said before I don't see any pressing need to use either of theese relatively uncommon acronyms elsewhere in the article. It only takes a word or two to clarify on the few points where there may be confusion. Plugwash (talk) 01:40, 26 June 2008 (UTC)

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?

Actually, FTP in old default mode "passive" does not bother to pass the layer 4 port number, but relies on the other end to use the layer 3 IP address to contact predefined TCP port 20 (in reverse direction). Usually connect request to the port 20 of the outside of the NAPT will not be translated to the originators inside IP and TCP port 20 ... except if there is a DMZ FTP server defined for the NAPT. Seikku Kaita (talk) 14:08, 6 October 2010 (UTC)

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)

Yes, a better example of layer 3 protocol information issues with NAT would be SIP which can include the IP address of a caller in a SIP invite sent to a call recipient from a SIP Proxy. —Preceding unsigned comment added by Owendelong (talk • contribs) 18:54, 11 September 2009 (UTC)

A Replacement Section -- What is NAT

I'll just leave this here for now, if you have more time before I do please consider moving it into the main article.

NAT is Network address translation.

It is used to convert the addresses and port numbers on internet packets between zones. Normally the zones are 'Internal' and 'Public' though others are possible.

This mainly applies TCP/IP and UDP/IP, IPv6 does not have a general need for address translation and other IP protocols don't have a well defined method of providing anything other then plain NAT. The exception being ICMP where the packets can usually be related to an existing TCP or UDP connection and so translated as part of that connection.

An IP packet has four values that can be used for normal NAT processing, these are converted between Internal and Public by the NAT router. They are the Source Address ( SA_I and SA_P ), the Source Port ( SP_I and SP_P ), the Destination Address ( DA_I and DA_P ) and Destination Port ( DP_I and DP_P )

When a packet arrives from an internal host bound for the public internet the router has the four Internal values SA_I, SP_I, DA_I, DP_I on the packet. The values DA_I and DP_I say where the packet has to go and must be copied unchanged to fields DA_P and DP_P on the public packet. The value SA_I is a private IP address and MUST be changed because it's not allowed on the internet. The SP_I (port) value may be changed if required. In addition the router must remember the change that it's made so that it can reverse this change when the inevitable reply to the packet arrives.

If the router has only one public IP address there's no choice; SA_P must be set to this address, if the router has multiple public addresses it gets to choose which one to put on the packet. If it has enough public IP addresses it can do 'Plain NAT' and have a direct mapping between the internal host IP address and a public address. But normally it has to share the available ports on one (or very few) public IPs between the internal hosts.

When the reply arrives it has the four values SA_P, SP_P, DA_P, DP_P. Because the packet is going in the opposite direction the machines that 'source' and 'destination' refer to are reversed related to the original outgoing packet, but it's the same four values that router translated the packet to when it sent the original request out.

This means the initial translation is:

SA_I, SP_I, DA_I, DP_I ==> SA_P, SP_P, DA_P, DP_P

Applying the rules on what changes are needed we get

SA_I, SP_I, DA, DP ==> Router-IP_n, SP_P, DA, DP

So for the reply the router needs a table where it can find SA_I and SP_I given any or all of the four public values.

For Plain NAT it assumes SP_I and SP_P are identical and indexes a table of internal IP addresses based on Router-IP_n.

The other named forms of NAT assume the is just one Router-IP so ignoring that...

For Full-cone NAT the index is SP_P one public port maps to one internal port. This variant is sometimes labelled PAT.

For Address restricted cone NAT the index is SP_P + DA, the port can be shared between internal hosts but not if they're talking to the same remote.

For Port-restricted cone NAT the index is SP_P + DA + DP, this can allow even more sharing; unless everyone wants to talk http to Google.

For all three of these forms the router usually tries to reuse the same mapping if a new connection arrives from either side that matches the parameters. Also two mappings will share Router-IP_n and SP_P if the connections have the same SA_I and SP_I even when DA and DP are different. But these rules don't apply to Symmetric NAT, for this the router limits who can connect based on the same sort of rule as Port-restricted cone NAT but instead of trying to make SP_I and SP_P identical it actively ensures that each mapping uses a different SP_P. (Perhaps even a random SP_P)

However, this distinction is a bit misleading, because a router doing Port-restricted cone NAT will act like one running Symmetric NAT if it's under a load where multiple internal hosts are trying to use the same SP_P (eg 1025) to communicate with well known remote servers on well known ports (Google via http again). This means that to do the two 'restricted' named versions of NAT the router must actually be doing full cone NAT but afterwards only accepting returning packets from the original remote host (&port) to be predictable in the way they're supposed to be.

What's more some NAT routers will record all the information required for a Port-restricted cone NAT but use a 'best match' process for packets that don't match exactly. This gives the effect of switching cones when there's a collision between mappings.

Some Operating systems distinguish between 'Source NAT' (SNAT) and 'Destination NAT' (DNAT) this distinction is related to how the NAT mapping is setup not how it works. Nevertheless, this can mean that the router will use different cones depending on which is used.

90.204.215.80 (talk) 16:48, 4 December 2010 (UTC)

"Security" changes

I disagree with the changes to the tone and substance of the article that were introduced by Seikku Kaita's recent edits.

To whit:

• Changing "is" to "has been" is not a language cleanup; it changes the meaning of the entire sentence.

• Is the number really "millions and millions"? Please cite. Even so, it seems the "and millions" part is hyperbole.

• Is it really "most of Europe"? Please cite. Same for the "Russia, Asia" part.

• Are only ADSL routers effective in protecting network assets? How about cable routers? SDSL routers? My (really ancient) Cisco 2600? Let's not qualify unless it's necessary and beneficial.

• More to the point, Information Security professionals will tell you that, while NAT/PAT may be a part of an effective program to secure an intranet and obscure its topology from prying eyes, it really doesn't protect customers from direct attack.

• Some people will not do business with an ISP that provides a simulated Internet connection through NAT/PAT and proxy devices, because it breaks so many things. While some messengers and Skype may work properly within such a walled garden, they do so because they are designed to. We should not be championing provisioning schemes that violate the word and spirit of the RFC-defined open Internet.

— UncleBubba ^{( T @ C )} 13:25, 29 September 2010 (UTC)

Some people will not do business with an ISP that provides a simulated Internet connection through NAT/PAT... In most cases there will be no choice (ok, no choice for reasonable price). I am not aware of any mobile internet provider, which would not use NAT (in some cases there is available non NATtted internet access, but it usually costs ~10x more for same usage). I do not know about satellite internet, but it is more costly anyway. -Yyy (talk) 16:07, 24 November 2010 (UTC)

IME you can get a VPN link to give you a public unfiltered static (or dynamic) IPv4 address for around a third the cost of a mobile connection. So if someone is trying to sell you 10x they're trying to screw you. 90.204.215.252 (talk) 09:08, 29 January 2011 (UTC)

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)

How about we start with a NAT behavior section. I'll add it to the todo list. --Kvng (talk) 19:16, 14 March 2011 (UTC)

"PAT" is an oxymoron

An address is an address and a port is a port. One does not translate or convert between them. Port Forwarding differs.

"PAT" doesn't exist in IETF specs that deal with address translation. Terms used in them are Source NAT (SNAT) and Destination NAT (DNAT). The "many-to-one" and "one-to-many" concepts aren't self-explanatory but neither is an oxymoron. Given that a single network may wish to connect with many others, a router that does NATing refers to the "one" in each instance. Networks that allow source NATing are prone to the simplest of Denial of Service attacks so most commercial ISPs drop Source NATed packets. Destination NAT is what allows a router to use the private IP address space (for more than one client).

Regarding the first sentence, consider an address is analogous to a high-rise building and each unit in that building as analogous to a port. Now consider two such high-rise buildings, A and B. If someone in building A sends a letter to someone in building B, they need to specify a unit number in building B, to receive the letter. The inverse is also true.

If a router translates a single IP address to any given port, 65,534 ports won't be able to receive connection requests. This doesn't seem reasonable. — Preceding unsigned comment added by 97.122.82.150 (talk) 06:39, 5 February 2012 (UTC)

a collection of weapons and military equipment stored by a country, person, or group.

Sure "arsenal" has a whatever-ary alternate definition of "an array of resources available for a certain purpose", but seriously folks, come on... who keeps "tool"s in their "arsenal"? I keep guns, bombs, germs, and chemicals in my arsenal. I keep tools in my toolbox. — Preceding unsigned comment added by 73.206.82.214 (talk) 19:48, 27 May 2015 (UTC)

Cleaning up

This article is a mess, the same thing is said several times in different ways. I've tried to make a start on cleaning it up but there is still much that needs doing. In particular:

• The article is mostly about one type of NAT (one to many nat) which while reasonable given that it is by far the most common type needs to be clearer.
• the "implementation" section is mostly repeating stuff that has already been said in slightly more detail. IMO we should probablly try and merge any relavent detail into the previous descriptions and then get rid of it.
• The analogy subsection of the implementation subsection is a TERRIBLE analogy, most NAT setups don't have a "receptionist" who can direct traffic to any internal machine, nor would their admins want one.
• the "advantages of PAT" section is a couple of sentances stating the obvious.
• the SNAT situation seems to be mostly a terminology definition, maybe it should be replaced with a more general terminology subsection explaining the terms used with NAT and any ambiguities that may occour.
• the "secure NAT" subsection of the SNAT section states the obvious interpretation of the term "secure nat" but doesn't say what is actually meant when a vendor says a "NAT" is secure
• This sentence is confusing: "The more common [More common than what??] arrangement is having computers that require end-to-end connectivity supplied with a routable IP address, while having others that do not provide services to outside users behind NAT with only a few IP addresses used to enable Internet access." I propose: "A common arrangement is to have computers that require end-to-end connectivity supplied with a routable IP address, while computers that do not provide services to outside users are behind NAT. Such an arrangement rations routable IP addresses." ThinkerFeeler (talk) 04:40, 6 October 2016 (UTC)

Any comments and anyone else want to take a stab at cleaning things up? Plugwash (talk) 08:49, 4 March 2011 (UTC)

Looks reasonable to me. Repetition is partly due to merges. I've taken the liberty of creating a WP:TODO list. --Kvng (talk) 15:13, 6 March 2011 (UTC)

External links modified (February 2018)

Hello fellow Wikipedians,

I have just modified one external link on Network address translation. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20100724011252/http://illuminati.coralcdn.org/stats/ to http://illuminati.coralcdn.org/stats/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 12:05, 16 February 2018 (UTC)

2.2 An Analogy - Pet peeve and question

"The analogy subsection of the implementation subsection is a TERRIBLE analogy, most NAT setups don't have a "receptionist" who can direct traffic to any internal machine, nor would their admins want one."

Actually that's a *GOOD* analogy for the following reason: Typically if a user connects out through a NAT to the "real world" InterNet, where all local users share a single IP (i.e. there's no 1-1 mapping between local IPs and public IPs, just *all* local IPs map to a single public IP), and requests a "call back", there's no way the "real world" host can do that "call back", because there's no way the "real world" host can guess how to address through that single public IP to the correct local IP.

MY PET PEEVE: Almost exactly the same problem occurs when I get a telephone call from a company that has only one public telephone number, mapping all private internal-outgoing lines to that one public telephone number, which shows up on my caller-ID unit. When I get back home, I see the caller-ID, so I try to call the person back, but I get the switchboard operator instead of the person who called me. I ask the operator to tell me who called me. I have the exact time (accurate to the minute). Surely the company automatically keeps track of which internal phone line makes a call to which external number at such-and-such minute, right? No. Kaiser Permanente has no way to track down whether it was my primary care physician, or the lab, or the emergencey room, or the IT staff, or any number of other likely suspects, or even a harassing telemarketing call (despite the fact I'm on the do-not-call list, which doesn't stop telemarketers). So I have to spend an hour calling the advice nurce and the IT department and ten other places at Kaiser Permanente asking whether each of them called me, and then wait several days to get letters in the mail telling me whether each called me or not. If it was something urgent, such as they discovered a cancer which requires immediate surgery, or they are calling me to tell me they've scheduled an appointment for me later the same day or the next day, I have no way to know until it's too late. So-far, this has happened several times, and there was not one case where I *ever* found out who really had called me. So maybe somebody could amend the metaphor to show how it really is not so bad a metaphor after all, that 1-to-many NAT precludes call-backs, analagously on Internet or telephone.

So anyway my question is: Does anybody have a workaround to somehow make it possible to do a call-back? For example, even though a single IP is used, there are lots of ports that could be used. So could somebody wanting a call-back tell the NAT to please reserve port foo on the single-IP to map to port bar on *my* local/private IP, for some specified period of time, then I tell the remote host to call me back *not* on port bar of the single-IP but rather port foo of the single-IP. 198.144.192.45 (talk) 09:33, 9 March 2011 (UTC) Twitter.Com/CalRobert (Robert Maas)

Please see WP:FORUM. I don't see how your question relates to development of the article. You might try Wikipedia:Reference_desk/Computing. --Kvng (talk) 14:49, 11 March 2011 (UTC)

Bad analogy. In the real world, desktop phone extensions are static and map to specific people or departments. It has been a long time since I have seen lots of static IP addresses on a network, usually the desktops are DHCP, besides which, if you did find the source, it would likely be a non-routable address of which there will be thousands of duplications, if not millions across the world. I'm not sure that NAT was designed to be primarily a basic form of security, but it is a great simple one, that is for sure mostly because it anonymises the 'caller'. To my knowledge, practically, it is very hard to determine if an address is a NAT gateway device, there are good clues, but not normally can anyone ascertain that any one device's address represents many thousands or the device is, for example, not a terminal service or proxy server. Also, the limitations of NAT devices are around memory and processor capability and since the device, usually a routing device of some sort, has finite resources, the session IDs are reused over and over. Only the device can tell you and only if it maintains a log, so you will need access to the device and like your broadband router at home, the deivce will be physically restricted to the management interface being accessible from the internal side only and if not, then by very rare and usually careless exception. You can see how NAT works at a practical level by using something VMware (two hosts and a virtual routner) and protocol analyser like SNORT or, to a lesser degree, NMAP. Thanks, Gund. — Preceding unsigned comment added by 116.199.214.34 (talk) 02:15, 30 May 2012 (UTC)

I think Robert's analogy is a good analogy. To answer Robert's question: Yes, there are workarounds to make it possible to do a call-back. Typically they all require servers with a globally-reachable IP address.

• (1) The simplest case: hosts behind a NAT router send messages to servers with a globally-reachable IP address. This network address translation article *should* explain how the NAT router initially creates and *remembers* a mapping between internal IP-address/port-number pair to external IP-address/port-number that (hopefully) lasts long enough for the entire conversation between the host and the server.
• (2) 2 hosts behind two *different* NAT routers want to communicate. They both send all their messsages to the same intermediate globally-reachable server, which forwards the data in the message similar to the way a NAT router forwards packets.
• (3) 2 hosts behind two *different* NAT routers want to communicate. They initially send a few messsages to some intermediate globally-reachable server, which replies with what it's figured out about the NAT router configuration of the *other* host. The hole punching (networking) (such as UDP hole punching and TCP hole punching) articles *should* explain how the hosts can then directly communicate to each other, with no more help from the globally-reachable server.

How can we make *this* article better, to more clearly explain (or at least link to other articles that explain) how to work-around the difficulties in communication caused by NAT ? --DavidCary (talk) 15:11, 27 February 2020 (UTC)

Source IP address in UDP and TCP ?

Gosh I'm looking at the packet formats for UDP and TCP and there are no source IP address fields. Source port yes, but not sourt IP address. "the source address in each packet is translated" and "the source address in each packet is translated" "mapped to a unique external source IP address" .. at worse this article is just plain wrong, or at best it is very confusing. I think some major edits are needed. See http://www.inetdaemon.com/tutorials/internet/udp/index.shtml for a udp packet diagram, and http://www.techrepublic.com/article/exploring-the-anatomy-of-a-data-packet/1041907 for a tcp packet diagram. No source IP address fields. — Preceding unsigned comment added by 216.19.190.96 (talk) 18:58, 18 July 2012 (UTC)

The IP addresses are stored in the IP packet header http://www.inetdaemon.com/tutorials/internet/ip/datagram_structure.shtml If you're sending UDP packets across an ethernet each one contains an ethernet packet with and ethernet header which contains an IP packet with and IP header which contains the UDP packet with the UDP header which contains the user data. 2001:470:1F09:10D6:215:FF:FE77:FD85 (talk) 09:32, 26 August 2012 (UTC)

I agree this is confusing, so I tried to clarify. Whenever this article mentions a "packet", it almost always refers to an IP packet with an IP header that includes the source IP address and the destination IP address. In practice the vast majority of IP packets contain either a UDP packet or a TCP packet, either one of which includes the source port and the destination port. How can we make this article less confusing? --DavidCary (talk) 04:49, 8 March 2020 (UTC)

Typo in SVG

The graphic misspells the word "destination" as "destenation".

That has already been pointed out at [1]. I have left the contributor a message. ~Kvng (talk) 14:41, 27 August 2020 (UTC)

IPv6 NAT in Enterprise Products

Hello, I'm revising the IPv6 part because it a lot of products (to the point that even OpenWRT included it) have a true one-to-many NAT66 function. I've cited https://blogs.infoblox.com/ipv6-coe/you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists/ for it but it seems that MrOllie thinks that's not an appropriate resource even though the article itself didn't have an upsell (I believe Infoblox doesn't even sell routers). Should I instead link the manuals individually? That seems to be too primary source to me to be honest, but it seems that general media doesn't cover enterprise IP products. Thanks. - 2001:4453:581:9400:C044:83DF:67DC:4E3 (talk) 16:52, 4 May 2022 (UTC)

See WP:RS. We don't use self published marketing materials such as vendor blogs as sources. If no one outside of vendor blogs and product manuals are covering this, it may be that this is a feature no one really cares about and isn't fit for mention in the encyclopedia. - MrOllie (talk) 17:12, 4 May 2022 (UTC)

@MrOllie: I do think that an exception under the second point of Wikipedia:Identifying and using self-published works#Acceptable use of self-published works (the writer is an expert in the networking field and has published articles in NetworkWorld that is related to his work https://www.networkworld.com/author/scott-hogg/), and that a better source hasn't been found despite exhaustive searches. An alternative is linking up to the primary sources individually, although primary sources isn't really preferred. I'm just really disappointed that the article states that IPv6 NAT don't exist when it has been implemented in multiple independent products. - 2001:4453:581:9400:C044:83DF:67DC:4E3 (talk) 17:31, 4 May 2022 (UTC)

It does not say that IPv6 NAT does not exist, it says it 'is not commonly used' which is true. MrOllie (talk) 17:35, 4 May 2022 (UTC)

I do think that the wording is deficient though, while it is uncommon in a home setting it is used in enterprise settings. I've instead resorted to linking to primary sources instead. - 2001:4453:581:9400:C044:83DF:67DC:4E3 (talk) 17:50, 4 May 2022 (UTC)

Do you have a source that says it is commonly used in enterprise settings? A few product manuals do not establish this. Many vendors produce 'solutions in search of a problem'. Even the infoblox blog says 'NAT is not needed or recommended.' MrOllie (talk) 17:51, 4 May 2022 (UTC)

Response to third opinion request (Disagreement about wording and sources of a section):

I am responding to a third opinion request for this page. I have made no previous edits on Network address translation and have no known association with the editors involved in this discussion. The third opinion process is informal and I have no special powers or authority apart from being a fresh pair of eyes.

Lack of WP:RELEVANCE leads me to think this should not be included, especially not with the phrasing "many products use..." as this is not attested to by the sources so far. If further attestation could be provided that, in fact, many products do support IPv6 NAT support it could be changed with slightly different phrasing. ★Ama TALK CONTRIBS 17:52, 5 May 2022 (UTC)

Hairpinning

Is there a reason to have a separate article on this? ~Kvng (talk) 02:06, 25 May 2022 (UTC)

Good catch. The article is largely redundant with the section Network_address_translation#NAT_hairpinning and that section is better written and with better context. A redirect and possible merge of anything not covered in the section looks like the best course to me. --{{u|Mark viking}} {Talk} 20:31, 25 May 2022 (UTC)

Symmetric NAT in "Methods of translation" implies no internal port is used

The previous three rows in the "Methods of translation" section table use iAddr:iPort variables to explain how they work. The Symmetric NAT row does not use these variables. Additionally, it does not otherwise refer to an internal port being used to generate the mapping/translation. I'm under the impression that "symmetric" NATs use internal IP and port. Should the internal port be added? If so, I could edit it to use similar verbiage as the above rows, which would make the table more cohesive narratively.

I haven't actually worked with NATs before so might be wrong here, so thought a discussion topic was best instead of an immediate edit. Aegatlin (talk) 22:52, 27 February 2023 (UTC)

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)

Echoing this rather old complaint. There's nothing in the article about the history of NAT. When were the techniques first described? When were they implemented in various systems? When did it become commonplace? --Bigpeteb (talk) 17:58, 1 May 2014 (UTC)

I agree that this article needs more about the history of NAT, so I started a "History" section with what little I know. Improvements are welcome. --DavidCary (talk) 04:19, 5 November 2023 (UTC)

Thanks for the contribution. There was some non-history content in that so I've trimmed it back. ~Kvng (talk) 13:58, 7 November 2023 (UTC)