Talk:Network address translation

message: 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)
thread_title:  Lead too long and technical 

message: 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)
replies: text: 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)
thread_title: Distinction between NAT and stateful firewalling

message: 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)
thread_title: style

message: 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)
thread_title: asynchronous nat

message: 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)
thread_title: mistake?

message: 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)
replies: text: I agree.  The first person ("I would respectfully...") needs to go too. --Chris (talk) 20:22, 15 May 2006 (UTC)

text: 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)
thread_title:  typo in the PDF linked at the article 

message: 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)
thread_title:  Citations/copyright 

message: 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)
replies: text: 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)
thread_title:  NAT and security 

message: 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)
thread_title:  Unclear Types-of-NAT Diagrams 

message: 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)
thread_title:  Unprintable diagrams? 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
thread_title:  Origins 

message: 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)
thread_title:  Missing Drawback: Port Shortage? 

message: 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)
replies: text: 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)
thread_title:  NAT behavior article needed 

message: 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)
thread_title:  Inappropriate argument about IPv6's making NATs useless 

message: 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:
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)
replies: text: 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)
replies: text: 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)
thread_title:  PAT popularly, but incorrectly, called simply "NAT" 

message: 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)
thread_title:  further expansion of a seemingly unrelated statement? 

message: 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)
replies: text: 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)
thread_title:  Self-referencing See-Alsos 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  "Security" changes 

message: 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 ( SAI and SAP
), the Source Port ( SPI and SPP ), the Destination
Address ( DAI and DAP ) and Destination Port (
DPI and DPP )
When a packet arrives from an internal host bound for the public internet
the router has the four Internal values SAI, SPI,
DAI, DPI on the packet. The values DAI
and DPI say where the packet has to go and must be copied
unchanged to fields DAP and DPP on the public
packet.  The value SAI is a private IP address and MUST be
changed because it's not allowed on the internet. The SPI
(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;
SAP 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 SAP,
SPP, DAP, DPP. 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:
SAI, SPI, DAI, DPI ==> SAP, SPP, DAP, DPP
Applying the rules on what changes are needed we get
SAI, SPI, DA, DP ==> Router-IPn, SPP, DA, DP
So for the reply the router needs a table where it can find SAI and SPI given any or all of the four public values.
For Plain NAT it assumes SPI and SPP are identical and indexes a table of internal IP addresses based on Router-IPn.
The other named forms of NAT assume the is just one Router-IP so ignoring that...
For Full-cone NAT the index is SPP one public port maps to one internal port. This variant is sometimes labelled PAT.  
For Address restricted cone NAT the index is SPP + 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 SPP + 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-IPn
and SPP if the connections have the same SAI
and SPI 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 SPI and SPP identical
it actively ensures that each mapping uses a different SPP.
(Perhaps even a random SPP)
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 SPP (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)
thread_title:  A Replacement Section -- What is NAT 

message: 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)
replies: text: 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)
thread_title:  Cleaning up 

message: 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)
thread_title:  "PAT" is an oxymoron 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Source IP address in UDP and TCP ? 

message: 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)
thread_title:  a collection of weapons and military equipment stored by a country, person, or group. 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 12:05, 16 February 2018 (UTC)
thread_title:  External links modified (February 2018) 

message: The graphic misspells the word "destination" as "destenation".
:That has already been pointed out at . I have left the contributor a message. ~Kvng (talk) 14:41, 27 August 2020 (UTC)
thread_title:  Typo in SVG 

message: 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  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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  IPv6 NAT in Enterprise Products 

message: Is there a reason to have a separate article on this? ~Kvng (talk) 02:06, 25 May 2022 (UTC)
replies: text: 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. -- {Talk} 20:31, 25 May 2022 (UTC)
thread_title:  [[Hairpinning]] 

message: 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)
thread_title:  Symmetric NAT in "Methods of translation" implies no internal port is used