Subject: [apps-discuss] New Version Notification for draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt

From: Franck Martin <[email-masked]>
Date: Thu, 5 Dec 2013 21:12:27 -0600 (CST)

I took some of the comments, and tried to clarify things. I hope I did not make it more complex. :P 

A new version of I-D, draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt 
has been successfully submitted by Franck Martin and posted to the 
IETF repository. 

Filename: draft-martin-smtp-target-host-selection-ipv4-ipv6 
Revision: 01 
Title: SMTP target host selection in Mixed IPv4/IPv6 environments 
Creation date: 2013-12-05 
Group: Individual Submission 
Number of pages: 8 
URL: http://www.ietf.org/internet-drafts/draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt 
Status: http://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-ipv6 
Htmlized: http://tools.ietf.org/html/draft-martin-smtp-target-host-selection-ipv4-ipv6-01 
Diff: http://www.ietf.org/rfcdiff?url2=draft-martin-smtp-target-host-selection-ipv4-ipv6-01 

Abstract: 
The Simple Mail Transfer Protocol (SMTP) is defined in [RFC5321]. 
Section 5 of that document describes the process of host selection. 
While locating the target host in IPv4 is well defined, this process 
is unclear for systems in IPv4 and IPv6 environments. This 
specification extends [RFC5321] to provide a standard way of 
selecting the target host in mixed environments.

---

From: Dan Wing <[email-masked]>
Date: Thu, 5 Dec 2013 22:04:02 -0800

... In some ways, this strategy is similar to the
   Happy Eveballs [RFC6555] strategy where web browsers initiate
   parralel connections to web servers using IPv4 and IPv6 and select
   the better connection. ...

RFC6555 does not describe initiating parallel connections, reference http://tools.ietf.org/html/rfc6555#section-5.5

I think your I-D would be improved by providing guidance for how long to wait for TCP connection itself.  I see http://tools.ietf.org/search/rfc5321#section-4.5.3.2.1 says 5 minutes for the initial 220, but it is silent on the TCP connection timeout.  A 5 minute delay for IPv6 path brokenness makes for slow mail delivery, and can convince many a system administrator to disable IPv6 to reduce user complaints of slow delivery.

-d

On Dec 5, 2013, at 7:12 PM, Franck Martin <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Franck Martin <[email-masked]>
Date: Fri, 6 Dec 2013 12:29:37 -0600 (CST)

----- Original Message -----
> From: "Dan Wing" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: "IETF Apps Discuss" <[email-masked]>
> Sent: Thursday, December 5, 2013 10:04:02 PM
> Subject: Re: [apps-discuss] New Version Notification for draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt
> 
> RFC6555 does not describe initiating parallel connections, reference
> http://tools.ietf.org/html/rfc6555#section-5.5

http://tools.ietf.org/html/rfc6555#section-4

Indicates TCP SYN are initiated on IPv4 and IPv6 and the first one that answers with a ACK wins, while the other one get a RST... Then this information is cached. We are not doing the same with SMTP, because there is already a process with MX to round robin connections. We just need to remember what worked.

> 
> 
> I think your I-D would be improved by providing guidance for how long to wait
> for TCP connection itself.  I see
> http://tools.ietf.org/search/rfc5321#section-4.5.3.2.1 says 5 minutes for
> the initial 220, but it is silent on the TCP connection timeout.  A 5 minute
> delay for IPv6 path brokenness makes for slow mail delivery, and can
> convince many a system administrator to disable IPv6 to reduce user
> complaints of slow delivery.
> 

SMTP is not XMPP. Once a connection is established there is PIPELINING and still you can send more than one email in a connection, and MTAs usually keep connections open in case they get another email to send. I don't think it is the purpose of this document to modify deeply the way SMTP works. Already overriding the DNS TTL on the MX made me a bit uncomfortable. Remember also, the purpose of this document is to encourage the MTA to remember what path works best for most email destinations.

I would also add if you claim to have IPv6 but cannot reach a lot of MXes on V6, then I think disabling IPv6 for mail till you get your network sorted out seems advisable.