Subject: Re: A few ipv6 questions
From: Hector Santos <[email-masked]>
To: John R Levine <[email-masked]>
Cc: Patrik Fältström <[email-masked]>, IETF SMTP list <[email-masked]>
Date: Fri, 24 Dec 2010 00:39:45 -0500
List-Id: <ietf-smtp.imc.org>

John R Levine wrote:
> 
>> Can we not turn this discussion into one that instead say:
>>> If you want to have this result, configure DNS this way:
> 
> Not really.  I want to give advice to people who are writing MTAs.  They 
> need to deal with whatever they find when they're trying to deliver mail.
> 
> As I hardly need to tell anyone here, we need to deliver mail on the 
> Internet we have, not the Internet we might want or wish to have at a 
> later time.

Which *should* means if you offer a public smtp service port, you have 
to support a IPv4 and MX service connection regardless.

-- 
Sincerely

Hector Santos
http://www.santronics.com

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 18 Dec 2010 10:38:03 -0500
From: "John R Levine" <[email-masked]>
To: "=?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?=" <[email-masked]>
Cc: "IETF SMTP list" <[email-masked]>
Subject: Re: A few ipv6 questions
Cleverness: None detected
Sender: [email-masked]

> Can we not turn this discussion into one that instead say:
>> If you want to have this result, configure DNS this way:

Not really.  I want to give advice to people who are writing MTAs.  They 
need to deal with whatever they find when they're trying to deliver mail.

As I hardly need to tell anyone here, we need to deliver mail on the 
Internet we have, not the Internet we might want or wish to have at a 
later time.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

Subject: Re: A few ipv6 questions
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Date: Sat, 18 Dec 2010 08:28:13 +0100
Cc: John C Klensin <[email-masked]>, IETF SMTP list <[email-masked]>
To: John R Levine <[email-masked]>
Sender: [email-masked]

Can we not turn this discussion into one that instead say:

> If you want to have this result, configure DNS this way:

And then have a few alternatives.

   Patrik

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: Fri, 17 Dec 2010 23:40:25 -0500 (EST)
From: John R Levine <[email-masked]>
To: John C Klensin <[email-masked]>
cc: IETF SMTP list <[email-masked]>
Subject: RE: A few ipv6 questions
Cleverness: None detected
Sender: [email-masked]

>> An MX lookup just returns the name of the MX.  There might be
>> A and AAAA records in the additional section, but there also
>> might not, and as I understand it, the order of records in a
>> section of a DNS response has always been considered to be
>> arbitrary.  So I agree, these tea leaves aren't worth reading.
>
> And that, of course, is exactly why the relevant section of 5321
> carefully avoids saying anything specific or normative about
> order of attempts.

Having reread 5321, I was surprised to see that it says that it says that 
the order of the A or AAAA records for a single name does matter.

Was that left over from olden days, or a recent addition?  Seems wrong 
either way.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

Date: Fri, 17 Dec 2010 23:02:44 -0500
From: John C Klensin <[email-masked]>
To: John R Levine <[email-masked]>, Ned Freed <[email-masked]>
cc: "Murray S. Kucherawy" <[email-masked]>, IETF SMTP list <[email-masked]>
Subject: RE: A few ipv6 questions
Sender: [email-masked]

--On Friday, December 17, 2010 18:42 -0500 John R Levine
<[email-masked]> wrote:

> 
>>> For simplicity one might try them in the order returned by
>>> the resolver, for example: Walk through the answer section
>>> and, if A, use AF_INET; if AAAA, use AF_INET6.
> 
> An MX lookup just returns the name of the MX.  There might be
> A and AAAA records in the additional section, but there also
> might not, and as I understand it, the order of records in a
> section of a DNS response has always been considered to be
> arbitrary.  So I agree, these tea leaves aren't worth reading.

And that, of course, is exactly why the relevant section of 5321
carefully avoids saying anything specific or normative about
order of attempts.

   john

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 17 Dec 2010 18:42:24 -0500
From: "John R Levine" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Cc: "Murray S. Kucherawy" <[email-masked]>, "IETF SMTP list" <[email-masked]>
Subject: RE: A few ipv6 questions
Cleverness: None detected
Sender: [email-masked]

>> For simplicity one might try them in the order returned by the resolver, for example: Walk through the answer section and, if A, use AF_INET; if AAAA, use AF_INET6.

An MX lookup just returns the name of the MX.  There might be A and AAAA 
records in the additional section, but there also might not, and as I 
understand it, the order of records in a section of a DNS response has 
always been considered to be arbitrary.  So I agree, these tea leaves 
aren't worth reading.

R's,
John

From: [email-masked]
Cc: "[email-masked]" <[email-masked]>, SM <[email-masked]>, John R Levine <[email-masked]>, IETF SMTP list <[email-masked]>
Date: Fri, 17 Dec 2010 15:12:40 -0800 (PST)
Subject: RE: A few ipv6 questions
To: "Murray S. Kucherawy" <[email-masked]>
Sender: [email-masked]

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> > Sent: Friday, December 17, 2010 9:26 AM
> > To: SM
> > Cc: John R Levine; IETF SMTP list
> > Subject: Re: A few ipv6 questions
> >
> >
> > > A dual stack client would favor the IPv6 address and try to connect
> > > to it first.
> >
> > Nope, not necessarily. In some cases it is entirely reasonable for a dual stack
> > client to try IPv4 before IPv6. Or use some other criteria to decide which
> > addresses to try.

> For simplicity one might try them in the order returned by the resolver, for example: Walk through the answer section and, if A, use AF_INET; if AAAA, use AF_INET6.

Right. This approach also makes sense in some load-balancing scenarios.
(Although it may be true today, there's no reason to assume that in the long
run the type of address has anything to do with service quality.)

I'll also add that this is exactly the sort of situation where standards that
try to say too much will end up giving bad advice and end up looking really
stupid.

				Ned

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>, SM <[email-masked]>
CC: John R Levine <[email-masked]>, IETF SMTP list <[email-masked]>
Date: Fri, 17 Dec 2010 11:29:25 -0800
Subject: RE: A few ipv6 questions
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, December 17, 2010 9:26 AM
> To: SM
> Cc: John R Levine; IETF SMTP list
> Subject: Re: A few ipv6 questions
> 
> 
> > A dual stack client would favor the IPv6 address and try to connect
> > to it first.
> 
> Nope, not necessarily. In some cases it is entirely reasonable for a dual stack
> client to try IPv4 before IPv6. Or use some other criteria to decide which
> addresses to try.

For simplicity one might try them in the order returned by the resolver, for example: Walk through the answer section and, if A, use AF_INET; if AAAA, use AF_INET6.

From: [email-masked]
Cc: John R Levine <[email-masked]>, IETF SMTP list <[email-masked]>
Date: Fri, 17 Dec 2010 09:26:05 -0800 (PST)
Subject: Re: A few ipv6 questions
To: SM <[email-masked]>
Sender: [email-masked]

> >A dual stack client tries 1.2.3.4 and a:b::c:d in either order, then
> >2.3.4.5 and b:c::d:e in either order.

> A dual stack client would favor the IPv6 address and try to connect
> to it first.

Nope, not necessarily. In some cases it is entirely reasonable for a dual stack
client to try IPv4 before IPv6. Or use some other criteria to decide which
addresses to try.

				Ned

				

Date: Fri, 17 Dec 2010 10:15:00 -0500
From: Tony Hansen <[email-masked]>
To: IETF SMTP list <[email-masked]>
Subject: Re: A few ipv6 questions
Sender: [email-masked]

On 12/17/2010 9:42 AM, John R Levine wrote:
>
>> A dual stack client would favor the IPv6 address and try to connect 
>> to it first.
>
> Why should it do that?

Some dual stack clients *are* configured to favor one versus the other. 
However, which one is favored is up to how it was administered.

     Tony Hansen

Date: Fri, 17 Dec 2010 09:56:07 -0500
From: Tony Hansen <[email-masked]>
To: IETF SMTP list <[email-masked]>
Subject: Re: A few ipv6 questions
Sender: [email-masked]

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

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 17 Dec 2010 09:42:29 -0500
From: "John R Levine" <[email-masked]>
To: "SM" <[email-masked]>
Cc: "IETF SMTP list" <[email-masked]>
Subject: Re: A few ipv6 questions
Cleverness: None detected
Sender: [email-masked]

> A dual stack client would favor the IPv6 address and try to connect to it 
> first.

Why should it do that?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

Date: Fri, 17 Dec 2010 06:21:46 -0800
To: John C Klensin <[email-masked]>
From: SM <[email-masked]>
Subject: Re: A few ipv6 questions
Cc: IETF SMTP list <[email-masked]>, John R Levine <[email-masked]>
Sender: [email-masked]

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 

Date: Fri, 17 Dec 2010 06:04:19 -0500
From: John C Klensin <[email-masked]>
To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <[email-masked]>, John R Levine <[email-masked]>
cc: IETF SMTP list <[email-masked]>
Subject: Re: A few ipv6 questions
Sender: [email-masked]

--On Friday, December 17, 2010 7:59 AM +0100 Patrik Fältström
<[email-masked]> wrote:

>> 3a. Let's say I have these DNS records:
>> 
>> baz.example MX 10 mail1.baz.example
>> baz.example MX 20 mail2.baz.example
>> mail1.baz.example A 1.2.3.4
>> mail1.baz.example AAAA a:b::c:d
>> mail2.baz.example A 2.3.4.5
>> mail2.baz.example AAAA b:c::d:e
>...
> I would say 3a is the only safe way of setting up DNS, but I
> am also a person that do not like multiple MX records as I
> think non-deliverable mail should be queued on the sender side.

Well, 3c would also work and has the advantage of making the
intent of the operator of the delivery system perfectly clear,
perhaps based on that operation's knowledge of her configuration.

3c would look like the following or any of the obvious
variations, i.e., one MX record, one target, no same-preference
randomness.

	baz.example. MX 10 mail1a.baz.example.
   baz.example. MX 15 mail1b.baz.example.
	baz.example. MX 20 mail2a.baz.example.
   baz.example. MX 25 mail2b.baz.example.
	mail1b.baz.example. A 1.2.3.4
	mail1a.baz.example. AAAA a:b::c:d
	mail2a.baz.example. A 2.3.4.5
	mail2b.baz.example. AAAA b:c::d:e
 
> Because of this, I think one should strongly recommend 3a as
> "the correct setup", possibly without the secondary MX.

Well, we are in a world in which the minimum requeueing time at
a client is widely ignored, often to retry for a day or less and
then reject/bounce.  If I'm the operator of a delivery server
and I know that my server, network, and/or connection are not
super-robust, multihomed, etc., it actually makes perfect sense
for me to set up a secondary MX that will accept the mail and
hold it as long as _I_ think necessary to overcome potential
outages (or to deliver it via some means that might not involve
SMTP-over-TCP).   Indeed, the same principle should apply in
this that applies to the rest of the network and we should treat
mechanisms that provide robustness through redundancy across the
network to be at least a reasonable tradeoff with, if not
superior to, super-hardened internally-redundant equipment and
networks.  I suggest that is especially true in a world in which
we have carefully and systematically made multihoming a small
network a PITA at best.

>...
   john

Date: Fri, 17 Dec 2010 05:49:10 -0500
From: John C Klensin <[email-masked]>
To: SM <[email-masked]>, John R Levine <[email-masked]>
cc: IETF SMTP list <[email-masked]>
Subject: Re: A few ipv6 questions
Sender: [email-masked]

--On Thursday, December 16, 2010 10:53 PM -0800 SM
<[email-masked]> wrote:

> 
> Hi John,
> At 21:52 16-12-10, John R Levine wrote:
>> I think the answers to these questions are obvious, but
>> they're not  obviously obvious, so:

I agree with SM's answers with one exception...

>...
>> 3a. Let's say I have these DNS records:
>> 
>> baz.example MX 10 mail1.baz.example
>> baz.example MX 20 mail2.baz.example
>> mail1.baz.example A 1.2.3.4
>> mail1.baz.example AAAA a:b::c:d
>> mail2.baz.example A 2.3.4.5
>> mail2.baz.example AAAA b:c::d:e
>> 
>> 3b. Let's say I have these DNS records:
>> 
>> 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
>> mail1a.baz.example A 1.2.3.4
>> mail1b.baz.example AAAA a:b::c:d
>> mail2a.baz.example A 2.3.4.5
>> mail2b.baz.example AAAA b:c::d:e
>> 
>> 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
> 
> Yes.
> 
>> A dual stack client tries 1.2.3.4 and a:b::c:d in either
>> order, then  2.3.4.5 and b:c::d:e in either order.
> 
> A dual stack client would favor the IPv6 address and try to
> connect to it first.

>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:

	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.

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.

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.   

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.

    john

best,
    john

Date: Thu, 16 Dec 2010 22:53:35 -0800
To: John R Levine <[email-masked]>
From: SM <[email-masked]>
Subject: Re: A few ipv6 questions
Cc: "IETF SMTP list" <[email-masked]>
Sender: [email-masked]

Hi John,
At 21:52 16-12-10, John R Levine wrote:
>I think the answers to these questions are obvious, but they're not 
>obviously obvious, so:
>
>1.  Let's say I have these DNS records:
>
>foo.example AAAA a:b::c:d
>foo.example MX 10 mail.foo.example
>mail.foo.example A 1.2.3.4
>
>Then a client would try to contact 1.2.3.4, and give up if it 
>can't.  A v6 only client can't send mail to foo.example.  No client 
>should try to send mail to a:b::c:d.

Yes.

>2. Let's say I have these DNS records:
>
>bar.example A 1.2.3.4
>bar.example MX 10 mail.bar.example
>mail.bar.example AAAA a:b::c:d
>
>A client would try to connect to a:b::c:d, and give up if it 
>can't.  A v4 only client can't send mail to bar.example.  No client 
>should try to send mail to 1.2.3.4.

Yes.

>3a. Let's say I have these DNS records:
>
>baz.example MX 10 mail1.baz.example
>baz.example MX 20 mail2.baz.example
>mail1.baz.example A 1.2.3.4
>mail1.baz.example AAAA a:b::c:d
>mail2.baz.example A 2.3.4.5
>mail2.baz.example AAAA b:c::d:e
>
>3b. Let's say I have these DNS records:
>
>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
>mail1a.baz.example A 1.2.3.4
>mail1b.baz.example AAAA a:b::c:d
>mail2a.baz.example A 2.3.4.5
>mail2b.baz.example AAAA b:c::d:e
>
>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

Yes.

>A dual stack client tries 1.2.3.4 and a:b::c:d in either order, then 
>2.3.4.5 and b:c::d:e in either order.

A dual stack client would favor the IPv6 address and try to connect 
to it first.

Regards,
-sm 

Subject: Re: A few ipv6 questions
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Date: Fri, 17 Dec 2010 07:59:10 +0100
Cc: "IETF SMTP list" <[email-masked]>
To: "John R Levine" <[email-masked]>
Sender: [email-masked]

On 17 dec 2010, at 06.52, John R Levine wrote:

> 3a. Let's say I have these DNS records:
> 
> baz.example MX 10 mail1.baz.example
> baz.example MX 20 mail2.baz.example
> mail1.baz.example A 1.2.3.4
> mail1.baz.example AAAA a:b::c:d
> mail2.baz.example A 2.3.4.5
> mail2.baz.example AAAA b:c::d:e
> 
> 3b. Let's say I have these DNS records:
> 
> 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
> mail1a.baz.example A 1.2.3.4
> mail1b.baz.example AAAA a:b::c:d
> mail2a.baz.example A 2.3.4.5
> mail2b.baz.example AAAA b:c::d:e
> 
> 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
> 
> A dual stack client tries 1.2.3.4 and a:b::c:d in either order, then 2.3.4.5 and b:c::d:e in either order.
> 
> Does this all look right?

I would say 3a is the only safe way of setting up DNS, but I am also a person that do not like multiple MX records as I think non-deliverable mail should be queued on the sender side.

Because of this, I think one should strongly recommend 3a as "the correct setup", possibly without the secondary MX.

If you do anything else (including 3b) the outcome might be random -- although I hope 3b is what in reality happens, and not that a single stack client give up when it tries one of the two MX that do not have connectivity with the version of the IP protocol it uses.

   Patrik

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 17 Dec 2010 00:52:06 -0500
From: "John R Levine" <[email-masked]>
To: "IETF SMTP list" <[email-masked]>
Subject: A few ipv6 questions
Cleverness: None detected
Sender: [email-masked]

I think the answers to these questions are obvious, but they're not 
obviously obvious, so:

1.  Let's say I have these DNS records:

foo.example AAAA a:b::c:d
foo.example MX 10 mail.foo.example
mail.foo.example A 1.2.3.4

Then a client would try to contact 1.2.3.4, and give up if it can't.  A v6 
only client can't send mail to foo.example.  No client should try to send 
mail to a:b::c:d.

2. Let's say I have these DNS records:

bar.example A 1.2.3.4
bar.example MX 10 mail.bar.example
mail.bar.example AAAA a:b::c:d

A client would try to connect to a:b::c:d, and give up if it can't.  A v4 
only client can't send mail to bar.example.  No client should try to send 
mail to 1.2.3.4.

3a. Let's say I have these DNS records:

baz.example MX 10 mail1.baz.example
baz.example MX 20 mail2.baz.example
mail1.baz.example A 1.2.3.4
mail1.baz.example AAAA a:b::c:d
mail2.baz.example A 2.3.4.5
mail2.baz.example AAAA b:c::d:e

3b. Let's say I have these DNS records:

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
mail1a.baz.example A 1.2.3.4
mail1b.baz.example AAAA a:b::c:d
mail2a.baz.example A 2.3.4.5
mail2b.baz.example AAAA b:c::d:e

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

A dual stack client tries 1.2.3.4 and a:b::c:d in either order, then 
2.3.4.5 and b:c::d:e in either order.

Does this all look right?

R's,
John

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.