> 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. > 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 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. 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". Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
