Talk:Network address translation
From Wikipedia, the free encyclopedia
 |
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. | |
| 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] 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] 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] 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)
