Re: Stupid NAT tricks and how to stop them.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]