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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
