On Oct 28, 2010, at 12:47 PM, Roger Marquis wrote: > Keith Moore wrote: >>> Please make the business case for my company's allowing your P2P app to >>> establish inbound connections without NAT? Without those specifics your >>> assertions have no identifiable logic. >> I don't give a damn about your company or its network. They are irrelevant >> to this discussion. It's your choice whether you want to run any particular >> app or not. > > This paragraph appears to be self-contradictory. How can you not care > what someone runs on their network on the one hand, and care whether they > use stateful NAT on the other?
First answer: This discussion is not about what you do on your network. It's about what IETF should endorse. What you do on your network is generally out of scope for the discussion, because nobody is proposing that IETF define any mechanism to forbid you from doing anything on your network. And you don't need IETF's endorsement in order to do what you want with your network. Do whatever you like, have a blast. (Just don't complain to us if what you do doesn't work well. You get to deal with the consequences of whatever choices you make.) Second answer: I don't care what you do in the privacy of your home, but I do care if you and lots of other people dump your waste into the street and let it rot there. Occasional deployment of NATs does little harm, but widespread deployment of NATs is like widespread dumping of toxic waste. I want people who actually have a legitimate need for NAT to be able to use NAT. But because widespread use of NAT does harm, I don't want to encourage NAT, and I want to try to make sure that the vast majority of users have better ways to solve their problems than NAT. I hope that if users are given better solutions, then they'll stop trying to use NAT where it makes no sense - like as a firewall. The idea that NATs only affect the networks behind them is false. When NATs are widespread, that affects the environment in which applications are expected to operate. There isn't a separate market for apps that work behind NATs. If only a relative few networks use NAT, then when applications don't work on those networks, it's clear that it's the NAT's fault. After all, the applications work just fine everywhere else. But when NATs are widespread, and they break applications, people blame the applications. It's not the applications' fault that they don't work with NAT. It's the fault of the network engineer who didn't design his network properly. The application is operating according to specifications, the NAT is not. But people often blame the applications because they take NATs as a given. Partially this is because of poor planning in protocols like DHCP and PPP - they were only designed to support a single host, rather than a network. Partially this is because CIDR resulted in somewhat shortsighted policies for address assignment to consumer customers of ISPs. Partially this is because NAT vendors often failed to inform their customers about the harm that their products did (especially when they labeled them as "internet connection sharing" and the like). Partially this is because most people don't have insight into what a particular application needs to do in order to operate well. Some applications work just fine through NAT, others don't. But this is generally because different kinds of applications quite naturally have different communications patterns - not because there's something wrong with the apps that don't work well through NAT. Third answer: On the other hand, when people carefully engineer and operate their networks for the sole purpose of running a limited number of well-understood applications, I don't have a problem with it at all if they happen to use NAT. e.g. I don't have a problem with F5 boxes even though they use NAT techniques. It's just another way of building a big server cluster. If you can't build a single host big enough to handle your traffic, you'll get better results if you use that sort of NAT box to demux your traffic than you will if you try to use multiple IP addresses to spread the load around. And it doesn't break anything when the clustering solution is carefully chosen to work well with the specific apps it is designed to support. It's not this kind of very specifically tailored use of NATs that causes problems, it's trying to impose NATs on general purpose networks that need to support a wide variety of apps and users. >> If you think there's something inherently wrong with P2P apps, you're >> deluded. But hey, it's your business. > > I doubt anyone has a bias against generic P2P. That's not the issue. What's > wrong is remote apps that expect to 1) initiate inbound connections and 2) > demand that they be allowed to initiate those inbound > connections to hosts unprotected by statefulness and to topologies > unabstracted by NAT. There's nothing at all wrong with those apps. Apps aren't supposed to have to know about network topology. The app doesn't know that it's making an inbound connection to your network and it has no way of knowing. (other than ICMP prohibited, which is almost never implemented and is also quite easily spoofed.) That might be a major problem with the Internet architecture, but it's not a problem with the app. Give the app a reliable way to know when it's circumventing a policy (along with a reasonable error message that the app can give to the user that tells him how to get the policy fixed if it's in error) and _then_ you can start expecting apps to be polite. The fact that a NAT is in the signal path is not an indication of policy because NATs are not designed as policy enforcement tools and are poorly suited as policy enforcement tools. That doesn't stop you from trying to use NATs as policy enforcement tools any more than it stops you from using your forehead to nail something to a tree. But just because you can try to do it doesn't mean it's a good idea. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
