> This sounds utterly reasonable to me.  I've had my share of troubles
> because of such misdesign, for instance in trying to get Kerberos to
> work right on machines with several IP interfaces.

Interestingly, Kerberos 4 breaks on machines with several interfaces,
but does tend to work with NAT, because it *doesn't* pass addresses
over the wire in the initial ticket request.  The KDC just puts the
address of the request in the ticket.  This is a demonstration of how
"just call getpeername" is not always the right answer.

Kerberos 5 works on machines with several interfaces, but tends to
break with NAT, because it does pass addresses over the wire in the
initial ticket request, and the KDC puts the requested addresses in
the ticket.  (There is a configuration option to request tickets valid
for all IP addresses, which will make krb5 work with NAT at the
expense of IP-level validation of tickets.)

So, given Kerberos's security design, accomodating multihoming breaks
NAT.  Perhaps this might affect your position.

http://www.cs.utk.edu/~moore/what-nats-break.html contains a fairly
exhaustive list of what NAT breaks (which is much more than "protocols
which pass addresses around").  Sometimes accomodating NAT requires
compromises in other areas.  When NAT breaks a protocol, it is unfair
to blame the protocol simply because it relies on behavior guaranteed
by IP.

A possibly confusing point is that IETF people tend to use "NAT" to
refer to devices which only translate addresses, and "NAPT" or "PAT"
to refer to devices which translate both addresses and ports.  We use
"NAT" to refer to NAPT.  (The rest of the world mostly uses "IP
masquerading" to refer to NAPT.)  As I understand it, pure NAT
typically has a pool of world-visible IP addresses and assigns a
potentially different source address to each new TCP connection or UDP
association, but does not modify port numbers.