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