--On Sunday, 06 January, 2008 09:30 +1300 Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
John,
Excuse front-posting but it probably works better than
interstitial comments for what I want to say.
The basic theory is supposed to be that faced with
a mixture of A and AAAA responses, the host will
by default prefer IPv6 and by default use RFC 3484
to choose among multiple IPv6 addresses. As far as
I know, that's running code for many SMTP servers.
But, in general, SMTP servers don't choose addresses. SMTP
clients do. The number of them that are 3484-compliant is not,
in my experience, large although there may be ones out there
that I don't know about or that have been fixed while I wasn't
looking. As far as the default IPv6 preference is concerned,
trying something, waiting for it to get a "not reachable" or,
much worse, time out, and then trying something else takes
sufficiently long that, until IPv6 reaches some critical mass,
configuring a 3484 sequence to prefer IPv6 in a production
environment just doesn't make a lot of sense right now.
Iljitsch's recent note covers some of the related issues much
better than I could and I have nothing to add to it.
It's also running code for Java 1.5 and up. (In both
cases, the host needs a dual stack supporting RFC 3484.)
In fact it's running code for any properly ported
application. But it does need some logic on top of
the getaddrinfo() call.
Part of what I'm suggesting is that "properly ported
applications" are not a large enough set to make trying to run
IPv6 attractive to those whose goal is just to get work (or
entertainment) done on the Internet... and that a large part of
the problem is that missing logic, so we are in agreement on
that at least.
Note that this set of preferences would apply *after*
any set of preferences applied at the FQDN level, e.g.
after MX preferences have been applied.
And what started this set of comments was only that, IMO, (i) we
have not done a good enough job yet of warning people that, if
SMTP-senders are following the protocols as now written, they
MUST have MX records for the target SMTP servers; there is no
default that involves IPv6 addresses, and (ii) it is fairly
easy, through carelessness and/or stupidity, to configure MX
records into a nasty state and we haven't given explicit,
standards-track (or BCP) advice about those "opportunities" and
how to avoid them.
It's also obviously that case that if an FQDN has both
A and AAAA records, all applications servers reached
at those addresses must support IPv4 and IPv6
respectively. No exceptions.
It may obviously be the case, but the implication of this is
that I dare not put an AAAA record up for a host that serves out
several protocols until all of those protocols are IPv6-ready.
That is an impediment to incremental conversion of a
multipurpose, dual-stack, host and is probably not optimal for
getting IPv6 deployed quickly. If it is our only choice, then
it is our only choice, but it is not an attractive one.
There's an operational fly in the ointment if the
DNS returns an AAAA record but no path exists to that
address; unfortunately we still have such issues
(exactly as we did for some A records 15 or 20 years ago).
In that case the client host would need to try all IPv6
addresses in sequence, followed by all IPv4 addresses in
sequence, until something works. That's more logic on top
of the socket API.
Yes. It also runs afoul of the current definition of SMTP and
MX routing, because a host is _explicitly_ not required to try
all addresses at a given preference level before moving on (or
even giving up). One can avoid getting into that problem by
being very careful about how many addresses might be tried at a
given preference level (which has some implications about hosts
with many listed addresses), but that is part of the "how to
configure this so it doesn't cause problems" issue that I refer
to above and in my original note.
And trying every address in sequence, without even caching the
information about what worked recently, is pathological from a
performance standpoint. Worse, as Iljitsch points out, the
ability to reach a host at a particular address does not imply
that the path used is optimal (or even better than "pessimal but
sort of works"). If one wants to find a decent path (somewhere
between optimal and pessimal), then one has to try all of them,
and make measurements, until either a satisfactory level of
performance is found or one has enough information to perform a
ranking. If one where going to go to all that trouble, one has
better be able to remember the results for at least a while.
And, at that point, the application (or that hypothetical socket
API) is beginning to resemble a router.
...
As Phill H-B has implied more than once, there's scope
for a library on top of the socket API that takes care
of this once and for all. Does anyone have such a library?
Phill's suggestion is, I believe, a different form of part of
the comment I'm making and, at the risk of putting words in his
mouth, part of what Keith has been saying for years. One can
say whatever one likes about shifting the burdens around or
difficulties in the e2e model in today's environment but the
bottom line is that, if one wants applications running smoothly
in an IPv6 (or dual-stack) environment, those applications need
to be able to call something when looking for an address record
that returns one plausible address in return for a name. My
personal belief is that the "something" is going to need to be
sufficiently intimate with the operating system to maintain some
memory of what it has done across applications and to take
advantage of information that no one application is likely to
have. And I fear that, if we don't get serious about that sort
of thing, we might as well predict IPv6 deployment over the next
decade by extrapolation from the last decade.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf