[comp.protocols.tcp-ip] Braden on secondary IP addresses

MRC@PANDA.PANDA.COM (Mark Crispin) (02/17/88)

     I've been in the NWG for at least 12 years, and I remember no
pronouncement that implementations *must* try all possible IP addresses.
I can think of just as many cases where it is undesirable as I can of
ones where it is desirable.

     Let's set the record straight on one thing.  The mailer in question
has no knowledge whatsoever of how to look up an address in a host table
or from a domain server.  It hasn't any notion of multi-homed hosts.  It
simply knows that it has to send a set of bits to a set of mailboxes at
a set of hosts.  The hosts are stored by name.  When the mailer attempts
to deliver a message, it does an operating system call which takes the
host name as an argument and returns a single IP address.

     Any change in IP address selection would have to be done at the
software at the other end of that system call.  One way for be for the
mailer to pass "advice" that a particular IP address has been shown to
fail.  Nobody is going to work on the host table software to do this.
The amount of work to do such a task is much more work that it would be
for Clive Dawson to upgrade his system to support domains.

     It would, I think, be relatively simple to put in such a function
into the domain software.  The only change to the mailer would be to
pass "advice"; presumably a 3 or 4 line code change.  I don't know what
sort of effort it would take to put this in the domain software.

     The question then becomes, what sort of criterion should the domain
software use beyond the current choice of "best" network, modified with
mailer "advice"?  Nobody has offered any suggestions.

     I again want to emphasize that the DEC-20 mailer does NOT "use the
first address and ignore the rest".  It has no way of knowing that any
other addresses exist; it is totally dependent upon external software
for any host information.  Don't assume that because your mailer has
internalized host table parsing routines that all mailers are written
that way.  I am a bit annoyed that the same people who are willing to
accept BITNET mailers which toss away RFC821 return path information
are quite happy to crucify software that isn't at fault.
-------