RE: Where NAT disenfranchises the end-user ...
|> From: Jon Mansey [mailto:JMansey@interpacket.net] |> Sent: Thursday, September 06, 2001 11:41 AM |> |> Isnt part of the solution here for ppl to write NAT-aware |> applications? |> |> I got this idea from a bugtraq post about gnutella that is able to |> detect and announce a different IP address than that of its actual |> private host IP based on what its internet-facing public IP is. |> |> Im sure there are a host of reasons why this is not a good idea from |> a security POV, but its a start, no? |> |> Im not disputing that a NATed connection should not be sold as "full |> Internet connectivity", I agree, but in terms of making it look and |> feel like one, I think we're close. Two software development houses, playing nice with each other, is more rare than two ISPs doing same. The bottom-line is that it comes right off the bottom-line. You can't deny that it's extra work/cost and effects time-to-market. Remember, in software development, it's the second 90% that kills the project. Consider the straw that broke the camel's back. Then consider that 80% of all software projects never make it to market. Then consider that most developers are NOT network engineers. They expect the network to *be there*, period.
Roeland Meyer wrote:
... Then consider that most developers are NOT network engineers. They expect the network to *be there*, period.
Or more completely, they expect the network to be transparent so that every port at the destination IP address connects to the same machine, and there is no operational restriction on which end initiates the communication. Tony
Or more completely, they expect the network to be transparent so that every port at the destination IP address connects to the same machine, and there is no operational restriction on which end initiates the communication. which of course *is* possible for at least one machine per visible IP address - even if additional IPs are masqed behind it.
Tony
Tony Hain writes:
Roeland Meyer wrote:
... Then consider that most developers are NOT network engineers. They expect the network to *be there*, period.
Or more completely, they expect the network to be transparent so that every port at the destination IP address connects to the same machine, and there is no operational restriction on which end initiates the communication.
Nicely put. Of course, that model does not correspond to reality, nor is it ever likely to. Traffic is always going to be controlled, filtered, redirected, and translated at administrative boundaries. Global, packet-level, end-to-end connectivity is dead, until somebody comes up with a compelling argument for why a Windows PC in an Internet cafe in Sofia, Bulgaria needs unfettered, packet-level access to a Coke machine in a break room at Sun Microsystems in Palo Alto. Like the battleship that radios a request for the lighthouse to move out of its way, detractors of NAT seem to be waiting for the world to modify itself to accomodate their end-to-end model. Eric Hall <ehall@ehsco.com> has expressed the position succinctly:
The fact is that I can write an Internet-compliant application in about two minutes that will break every NAT ever sold, simply because they don't have a proxy for the protocol. NATs violate fundamental Internet principles.
Many stupid things can be done in about two minutes. This particular fundamentalist tenet has been at odds with reality since the first firewall was installed, and will only become more so. Jim Shankland
From: "Jim Shankland" <nanog@shankland.org>
Nicely put. Of course, that model does not correspond to reality, nor is it ever likely to. Traffic is always going to be controlled, filtered, redirected, and translated at administrative boundaries. Global, packet-level, end-to-end connectivity is dead, until somebody comes up with a compelling argument for why a Windows PC in an Internet cafe in Sofia, Bulgaria needs unfettered, packet-level access to a Coke machine in a break room at Sun Microsystems in Palo Alto.
Or why a team of gamers need to be able to coordinate n-way traffic between them without each of them having listeners Or why a protocol would need to embed addressing into the datastream Not like any of that will ever happen.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eric Hall <ehall@ehsco.com> has expressed the position succinctly:
The fact is that I can write an Internet-compliant application in about two minutes that will break every NAT ever sold, simply because they don't have a proxy for the protocol. NATs violate fundamental Internet principles.
Many stupid things can be done in about two minutes. This particular fundamentalist tenet has been at odds with reality since the first firewall was installed, and will only become more so.
Jim Shankland
Oh yes, the firewall. That convenient device that network software developers can assume will always pass port 80 and 443 traffic. So everything uses port 80 and 443 in the future Internet, and we're all the better for it. Uh-huh. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBO5kHyEksS4VV8BvHEQJI6wCgm6JoiS11I5g4NkrxnDaZU4nlTAkAoMMu ll66gu/3u8oaOx+0RGc7bvF+ =+9g3 -----END PGP SIGNATURE-----
Many streaming/multimedia apps try port 80 http if their typical range is not open.. Brian "Sonic" Whalen Success = Preparation + Opportunity On Fri, 7 Sep 2001, Mike Batchelor wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eric Hall <ehall@ehsco.com> has expressed the position succinctly:
The fact is that I can write an Internet-compliant application in about two minutes that will break every NAT ever sold, simply because they don't have a proxy for the protocol. NATs violate fundamental Internet principles.
Many stupid things can be done in about two minutes. This particular fundamentalist tenet has been at odds with reality since the first firewall was installed, and will only become more so.
Jim Shankland
Oh yes, the firewall. That convenient device that network software developers can assume will always pass port 80 and 443 traffic. So everything uses port 80 and 443 in the future Internet, and we're all the better for it.
Uh-huh.
-----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQA/AwUBO5kHyEksS4VV8BvHEQJI6wCgm6JoiS11I5g4NkrxnDaZU4nlTAkAoMMu ll66gu/3u8oaOx+0RGc7bvF+ =+9g3 -----END PGP SIGNATURE-----
participants (8)
-
Brian Whalen -
Christian Kuhtz -
David Howe -
Eric A. Hall -
Jim Shankland -
Mike Batchelor -
Roeland Meyer -
Tony Hain