Shawn wrote: >> NAT and the associated loss of the original peer-based structure of the >> Internet has done immeasureable damage to Internet innovation. Asymmetric >> network connections and ISP terms of service that restrict home "consumers" >> from running "servers" have also done some damage, but we can mostly deal >> with the former and just ignore the latter. NAT, on the other hand, is a >> killer.
Amen. I meet 'network technicians' on a regular basis who do not understand the distinction between routing and NAT'ing. Jody wrote: > Am I to understand this to mean that resolving this issue is not a priority > for the tahoe development team? I don't mean to be rude at all, but I think you may be operating at a higher layer (application) than this problem calls for. The common wisdom is that double NAT'ing is bad (mmmkay?), especially idea if you're running anything that something else might need to connect to. Most ISPs that put their customers on NATs also operate a public-IP space VLAN for people that this causes problems for. Alternatively, get rid of your NAT device, which takes you down to the much more common (still kludgy) single-NAT environment. Obviously, use host firewalls in this case. There might be an incidental fix provided by a persistent connection to the helper/introducer/other nodes/etc. However, in general (not specific to Tahoe), I would call double-NAT an unsupportable use-case. The best solution is to remove the problem, or to use an IPv6 broker as has been suggested, in order to circumvent it with a useful addressing schema. I don't think the Tahoe devs should spend a considerable amount of time fighting this battle. As has been pointed out, Tahoe is not the first project that NAT has cause enormous problems for - and your ISP will discover this as they try to scale and hit a brick wall. Best Regards, Nathan Eisenberg _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
