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.
-------pvm@venera.isi.EDU (Paul Mockapetris) (02/19/88)
Mark, Bob, There are real issues behind this debate, and they are 1) what are the right policies with regard to hosts with multiple addresses and 2) where should the policies be implemented. It would be nice if everyone agreed what the rules are, but the waters are pretty muddy. There can be a large difference in performance depending on which address you use. My experience with domain and mail services suggests that sometimes a host offers different services on different addresses, and sometimes only a subset of the addresses are reachable due to gateway, etc factors. The bottom line is that sometimes whether you win or lose depends on the source and/or destination address you choose. There may always be a best address, but it isn't always possible to know which one it is without empirical information. I can always prefer destination addresses which share a common network, but sometimes the problem is "Given N non-local class C addresses, which one should I use?" Since the answer would seem to depend on both the identity of the source and the identity of the destination, it doesn't seem that either can solve the problem alone. Its not really just a mail issue. For example, domain resolvers and mailers have similar options. [A resolver has to decide (1) which sending address to use, (2) which name server to ask, and (3) which destination address to use when it targets a query. A mailer has to decide (1) which sending address to use (2) which MX RR (i.e. mail server) to use, and (3) which destination address to use. The parallels continue when you think about what to do in case of errors, how you tradeoff network resources vs local resources vs time to finish a request, etc. Admittedly, there are also large differences, but dealing with multiple addresses is an issue which comes up whenever you have such network services.] The domain system won't solve this problem. In fact, it will make it worse by spreading multiple addresses in more contexts. What we need is a consensus on policies regarding the use of multiple addresses and single module that can be used by all applications to implement the policies. (Maybe we have discovered one of the missing layers in the Internet 7 layer cake.) paul