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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf