Fred Baker wrote: > > On Mar 23, 2009, at 11:38 AM, Roger Marquis wrote: > >> Residential and commercial network owners and operators don't want their >> internal hosts to be directly reachable. > > That's a fairly sweeping statement. At my company, there are a huge > number of hosts that we don't want to be externally accessible as > servers but which we allow to be clients of various sorts. At the > network layer, the difference between a request and response is not > visible. > > One can certainly make one's hosts unreachable. One can not advertise > them in DNS, one can enumerate them using a prefix that isn't routed > outside (and perhaps isn't even routed to the DMZ), and so on. Oh yes, > there exist filters, which are the usual strategy of choice - stateful > firewalls act as diodes, allowing session initiation in one direction > but not the other. If someone doesn't want to authorize external access > to a host, that's not very hard to enforce. That is not the purpose - > and explicitly not a feature - of NAT66. Prophylactic security, which > has all of the issues and benefits of contraceptive prophylactics, is > quite separate. > > I think the question Keith and others are asking is not whether a system > is reachable when they are not authorized to reach it. The dreamers in > the crowd might like to ignore that, but those of us who live in the > real world can ignore them. The question is the reachability of systems > that one is authorized to reach. > > Keith is arguing that end to end addressing is required to implement > that.
I'm arguing that applications need to be able to accept traffic at global addresses in order to implement that reliably and without a lot of additional complexity. The app doesn't care what the address looks like on the wire, but it does (ideally) want the address to be the same for each of it its (current and potential) peers. That's by far the simplest model for an application to deal with. Whenever a NAT (any kind of NAT) provides additional addresses at which an application can accept traffic (and if there's any bias at all such that some of those addresses work better than others for a given peer), that increases the burden on the application, because it has to make a good choice about which source and destination addresses to use. (The burden is even worse for P2P apps.) In the extreme case this is about reachability, in less extreme cases it's about performance and reliability, but it's more-or-less the same issue. > My point is that the exact number of the address is less important > than the ability to identify the host, given that the application itself > is not trying to know something about network layer addressing. The application doesn't care about the exact number of the address. However it might care that the same address work for all of its peers, or that if it opens multiple connections to a peer that they all originate at the same address, or that each of its peers to which it has an open connection will see the same source address, etc. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
