Hi John,
At 02:49 17-12-10, John C Klensin wrote:
>From a mail specification standpoint, John is correct.
Yes.
While a preference for IPv6 is part of various dual stack
specifications, it may not be operationally wise in all cases.
Put differently, application of a minimal change principle to
the RFC 974 / 5321 MX rules would say: "follow those rules but
do not attempt to connect to anything to which you are incapable
of connecting". That would be even more clear if we examine a
(very) slightly more complex example:
4. Let's say I have these DNS records (note that I've
made a small notational correction to the records, but
assume that John's intent was the same as what this
shows more explicitly):
baz.example. MX 10 mail1a.baz.example.
baz.example. MX 10 mail1b.baz.example.
baz.example. MX 20 mail2a.baz.example.
baz.example. MX 20 mail2b.baz.example.
baz.example. MX 10 mail1c.baz.example.
mail1a.baz.example. A 1.2.3.4
mail1b.baz.example. AAAA a:b::c:d
mail1c.baz.example. A 5.6.7.8
mail2a.baz.example. A 2.3.4.5
mail2b.baz.example. AAAA b:c::d:e
A dual-stack client selects one of 1.2.3.4, a:b::c:d, and
5.6.7.8 in any order, then, if necessary, tries one of the
remaining set in either order, then one of the remaining pair,
then the last one. Whether it tries both IPv4 addresses before
either IPv6 one, both IPv6 addresses before either IPv4 one, or
alternates is strictly up to the client and may (at the client's
option), be randomized. Only then does it (optionally, but
strongly recommended) move on to the 2.3.4.5 and b:c::d:e pair.
Agreed. As part of the sending strategy, it would be good if the
address selection is randomized.
A client supporting either IPv4 or IPv6 but not the other
behaves identically to the dual-stack one except that it doesn't
try any addresses for which it does not have support. And a
client that is configured to not use some addresses (or that has
cached some indicative knowledge for a short time) doesn't
bother to try the excluded addresses either, no matter what the
criteria were for the exclusion.
Yes.
If this story has a moral, it is that, if the operator
controlling the DNS records and the final destination server has
a preference at to the order in which things are tried, it may
be better off expressing that preference as in John's examples 1
and 2, rather than trusting to luck as in examples 3 and 4.
Thus it has been since RFC 974 -- nothing really new here other
than the application of common sense.
Yes.
On the other hand, I tend to agree with John that it wouldn't be
a bad idea to have this a bit more explicit. But we actually
did do so in Section 5.2 of RFC 5321. I suppose that, if we
hadn't had our YAMs mashed before they were cooked, we might
have added this set of examples or something that would more
give their flavor, to that section. I note, fwiw, that the -04
version of the preevaluation template for 5321 does not call
this section out as needing change. If someone were motivated,
it wouldn't be a bad idea to update it (and to note that it
would have expired if it weren't in a "wait forever" state) or
to generate an erratum-like note to remind the forgetful editor.
I guess that nobody wanted to revisit the long discussion about
Section 5 of RFC 5321. Section 5.2 might benefit from having a set
of examples, as you mentioned above.
Regards,
-sm