On Tue, Mar 28, 2006 at 02:33:25PM -0500, Keith Moore wrote:
Precisely. Just what is this fetish about keeping the IP address the same as
the packet travels?
it's called good engineering. eliminating needless complexity.
..and NAT isn't good engineering. But it may be good enough.
If there is a way for the host to determine that it is behind a NAT and to
request external registration of necessary ports the whole process can be
made completely transparent to the hosts at each end.
sounds nice, but the actual situation is more complicated:
apps behind a NAT need to have a way to have the NAT allocate
an address/port pair for incoming traffic, set up mappings to a
local address/port pair that is used by the app, and retain that
mapping for as long as the app is listening to the local address/port
pair.
apps behind a NAT also need to be able to ask the NAT about external
address/port bindings for traffic that they originate.
in either case, the external address/port pair needs to work equally
well from inside or outside the NAT.
the whole arrangement needs to work with nested NATs
This would qualify as a NAT enhancement. This is available now
via manual methods on the devices I've used. This might benefit from
automation.
there needs to be a reliable way for apps to automatically discover the
NAT and whether it supports the extensions.
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.
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. I would be very surprised
if there weren't many real life examples of this in practice.
Austin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf