|
Re: A few ipv6 questions
2010-12-17 09:11:24
On 12/17/2010 5:49 AM, John C Klensin wrote:
... In both of these examples, a v4 client tries 1.2.3.4, then
2.3.4.5.
In both of these examples, a v6 client tries a:b::c:d, then
b:c::d:e
...
> From a mail specification standpoint, John is correct.
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:
Given that IPv4-only clients are only going to look for MX and A
records, they shouldn't even see the AAAA records.
Similarly, IPv6-only clients are only going to look for MX and AAAA
records, so they shouldn't even see the A records.
They would also ignore SRV records, or any other RR set you may care to
mention.
I think the rules are explicit enough there.
...
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 support adding more examples where they're useful, like these. I
recently saw an example of this where someone got it wrong and couldn't
understand why they stopped receiving mail. A simple example to point
him to would have prevented it from happening in advance. I was even
thinking that it would be useful to be able to point to a simple RFC
that went through various examples on how to set up their A, AAAA and MX
records.
In the example, though, I'd be more explicit about what happens in the
IPvX-only environment, as in:
-- In both of these examples, a v4 client tries 1.2.3.4, then 2.3.4.5.
(It doesn't see the AAAA records.)
-- In this example, a v4 client would not find an address record for
mail1a.baz.example, try 1.2.3.4 for mail1b.baz.example, would not find
an address record for mail2a.baz.example, and would try 2.3.4.5 for
mail2b.baz.example.
Tony Hansen
|
|