> > a big wrinkle is when private networks are interconnected via > > NATs - there's no "external" addresses that can be used there. > > > Currently (as I understand it) the solution involves static > natting both sides. Again, this could probably benefit from automation. No > question that this adds complexity. Multihoming becomes much more difficult, > for example. that's one example. there are many others. > > another big wrinkle is apps that use well-known ports, and the > > potential for conflicts. that alone prevents your suggestion from > > making the whole process "completely transparent". > > This goes back to the earlier tcpmux discussion. > But using httpd as an example, one could use split horizon dns and > set up the nat (really a bastion in this example) as a proxy server. Good > engineering? Doubtful. Good enough? Probably. when you say good enough, you have to consider who is asking the question and whether they really know enough to be answering it. it's not good enough for the application developer who has to cope with the lack of a good way to do referrals across addressing domain boundaries, the lack of any naming for addressing domains, and the inability of apps to tell which interfaces are in which addressing domains. the typical user, on the other hand, might _think_ that the solution is good enough because he doesn't ever see the apps that he doesn't get to run. > I would be very surprised > if there weren't many real life examples of this in practice. there are. but this is an example of why existing practice is not an indicator of goodness. the only workarounds for NATs that make any sense are those which effectively allow apps to operate in a non-NATted world, and which, in the long term, render NATs superfluous. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf