On Oct 29, 2010, at 4:18 AM, S.P.Zeidler wrote: > Thus wrote Keith Moore ([email protected]): > > [...] >> - Define a single, standard, mechanism that applies regardless of which kind >> of NATs are being used, that lets applications cope. This includes things >> like finding an global transport address that's associated with an internal >> transport address, creating bindings (subject to policy) that allow incoming >> connections, maintaining bindings in stateful NATs, destroying bindings when >> they're no longer used, hooks to allow both application and host OS access >> to such functions, support for split NAT, etc. (for there to be a single >> standard mechanism it has to be more versatile than NAT66 needs) > > You seem to fail to grasp that in a network where NAT is not forced on the > local network admin for lack of address space, but chosen as a vote > of no confidence regarding the hosts that are being NATted and because of > scaling problems, applications that need what you propose will go splat on > the firewall anyway.
You seem to fail to grasp that there is a far wider variety of things that people and enterprises legitimately want to do with their networks, and a far wider variety of legitimate patters for application traffic, than you can imagine. In other words, you're simply incorrect. And the effect of what you're trying to do is to cripple the Internet architecture so that nobody can run apps that don't conform to your narrow-minded ideas of how apps should work. > In a world where even subnets are plenty, if I have a few hosts that I want > to run an app like that I can assign them their very own public /64 in their > own DMZlet. As long as you're trying to make a destination IP address be an authentication token for your hosts, your security is always going to be very weak and fragile. Keith
_______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
