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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf