IPv6 and email routing, was Re: AAAA records to be added for root servers

Tony Finch <dot@dotat.at> Mon, 07 January 2008 19:44 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxtF-0005l1-22; Mon, 07 Jan 2008 14:44:05 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxtD-0005kv-DA for ietf@ietf.org; Mon, 07 Jan 2008 14:44:03 -0500
Received: from ppsw-9.csi.cam.ac.uk ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBxtC-0007Pg-Rj for ietf@ietf.org; Mon, 07 Jan 2008 14:44:03 -0500
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([]:33920) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk []:25) with esmtpa (EXTERNAL:fanf2) id 1JBxt8-0001HJ-To (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Mon, 07 Jan 2008 19:43:58 +0000
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1JBxt8-0003Wp-7H (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Mon, 07 Jan 2008 19:43:58 +0000
Date: Mon, 07 Jan 2008 19:43:58 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: John C Klensin <john-ietf@jck.com>
In-Reply-To: <80DC2140473447FAEA5CCBE5@p3.JCK.COM>
Message-ID: <alpine.LSU.1.00.0801071927290.15011@hermes-1.csi.cam.ac.uk>
References: <49878589-D2C2-485F-98D2-4A57127CFDFB@icann.org> <6FA23A8DC8CD65A0CF3B61EA@p3.JCK.COM> <20080104200152.GA13082@boreas.isi.edu> <80DC2140473447FAEA5CCBE5@p3.JCK.COM>
User-Agent: Alpine 1.00 (LSU 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: ietf@ietf.org, Bill Manning <bmanning@ISI.EDU>
Subject: IPv6 and email routing, was Re: AAAA records to be added for root servers
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

On Fri, 4 Jan 2008, John C Klensin wrote:
> On Friday, 04 January, 2008 12:01 -0800 Bill Manning <bmanning@ISI.EDU> wrote:
> >
> > The general answer when needing to communicate between similar
> > applications that run on different address families has traditionally
> > been the application layer gateway (ALG) ...

MTAs *are* ALGs.

> [...] If the MX resolution doesn't work smoothly for IPv6, then the DNS
> isn't IPv6-ready no matter how many AAAA records are defined and spread
> around. [...] I hope the additional information rules have been adjusted
> if needed to encourage return of relevant AAAA records if they exist
> [...]

Yes AAAA records are returned in the additional section just like A
records. However this behaviour is less useful than one would hope,
because of the RFC 2181 rules about the TC bit. In particular, it is not
set when RR sets have been dropped from the additional section of the
reply. This means an MTA can't immediately tell the difference between an
IPv4-only MX record and a dual-stack MX record where the IPv6 addresses
have been truncated. It must do extra DNS lookups to resolve the
ambiguity, which (at the present time) is usually a waste of effort. The
extra lookups are not optional because you can also get dual-stack MX
replies in which the A records have been dropped, which can (and does)
lead a naive IPv4-only MTA to think erroneously that it cannot reach the
other server.

f.a.n.finch  <dot@dotat.at>  http://dotat.at/

Ietf mailing list