Internet Engineering Task Force Motonori Nakamura
INTERNET-DRAFT Kyoto University
Expires: Novermber 10, 2004 Jun-ichiro itojun Hagino
IIJ Research Laboratory
May 10, 2004
SMTP Operational Experience in Mixed IPv4/v6 Environments
draft-motonori-dualstack-smtp-requirement-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration will
be Novermber 10, 2004.
Abstract
This document talks about SMTP operational experiences in IPv4/v6 dual
stack environments. As IPv6-capable SMTP servers are deployed, it has
become apparent that certain configurations of MX records are necessary
for stable dual-stack (IPv4 and IPv6) SMTP operation. This document
clarifies the problems that exist in the transition period between IPv4
SMTP and IPv6 SMTP. It also defines operational requirements for stable
IPv4/v6 SMTP operation.
This document does not define any new protocol.
NAKAMURA, HAGINO Expires: Novermber 10, 2004 [Page 1]
DRAFT SMTP in Dual Stack Environments May 2004
1. Introduction
Delivery of mail messages to the final mail drop is not always done by
direct IP communication with submitter and final receiver, and there may
be some intermediate hosts that relay the messages. So it is difficult
to know at message submission (also at receiver side) that all
intermediate relay hosts are properly configured. It is not so easy to
configure all systems consistently since the DNS configuration used by
mail message delivery systems is more complex than other Internet
services. During the transition period from IPv4 to IPv6, more care
should be applied to IPv4/v6 interoperability.
This document talks about SMTP operational experiences in IPv4/v6 dual
stack environments. As IPv6-capable SMTP servers are deployed, it has
become apparent that certain configurations of MX records are necessary
for stable dual-stack (IPv4 and IPv6) SMTP operation.
This document does not discuss the problems encountered when the sending
MTA and the receiving MTA have no common protocol (e.g. the sending MTA
is IPv4-only while the receiving MTA is IPv6-only). Such a situation
can be resolved by making either side dual-stack or by making either
side use a protocol translator (see Appendix A on issues with protocol
translator).
2. Basic DNS Resource Record Definitions for Mail Routing
Mail messages on the Internet are typically delivered based on Domain
Name System [Mokapetris, 1987] . MX RRs are looked up in DNS to
retrieve the names of hosts running MTAs associated with the domain part
of the mail address. DNS lookup uses IN class for both IPv4 and IPv6,
and similarly IN MX records will be used for both IPv4 and IPv6 for mail
routing for for both IPv4 and IPv6. Hosts which have IPv6 connectivity
and want to have the mails delivered also using the IPv6 must define
IPv6 addresses for the host name as well as IPv4 IP addresses [Thomson,
2003] .
An MX RR have two parameters, a preference value and the name of
destination host. The name of destination host will be used to look up
an IP address to initiate SMTP connection [Partridge, 1986] .
For example, an IPv6-only site may have the following DNS definitions:
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
mx10.example.org. IN AAAA 2001:db8:ffff::2
In the transition period from IPv4 to IPv6, there are many IPv4-only
sites, and such sites will not have mail interoperability with IPv6-only
sites. For the transition period, all mail domains should have MX
records such that MX targets with IPv4 and IPv6 addresses exist, e.g.
NAKAMURA, HAGINO Expires: Novermber 10, 2004 [Page 2]
DRAFT SMTP in Dual Stack Environments May 2004
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
IN A 192.0.2.1
mx10.example.org. IN AAAA 2001:db8:ffff::2
IN A 192.0.2.2
But, not every MX target may support dual-stack operation. Some host
entries may have only A RRs or AAAA RRs:
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
mx10.example.org. IN A 192.0.2.1
The following sections discuss how the sender side should operate with
IPv4/v6 combined RRs (section 3) and how the receiver should define RRs
to maintain interoperability between IPv4 and IPv6 networks (section 4).
3. SMTP Sender Algorithm in a Dual-Stack Environment
In a dual-stack environment MX records for a domain resemble the
following:
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN A 192.0.2.1 ; dual-stack
IN AAAA 2001:db8:ffff::1
mx10.example.org. IN AAAA 2001:db8:ffff::2 ; IPv6-only
For a single MX record there are multiple possible final states,
including: (a) one or more A records for the IPv4 destination, (b) one
or more AAAA records for the IPv6 destination, (c) a mixture of A and
AAAA records. Because multiple MX records may be defined using
different preference values, multiple addresses based on multiple MX's
must be traversed. Domains without MX records and failure recovery
cases must be handled properly as well.
The algorithm for a dual-stack SMTP sender is basically the same as that
for an IPv4-only sender, but it now includes AAAA lookups of MX records
for SMTP-over-IPv6 delivery. IPv4/v6 dual stack destinations should be
treated just like multihomed destinations as described in RFC2821
[Klensin, 2001] section 5. When there is no usable destination address
record found (for example, the sender MTA is IPv4-only and there are no
A records available) the case should be treated just like MX records
without address records, and deliveries should fail just like such
cases.
NAKAMURA, HAGINO Expires: Novermber 10, 2004 [Page 3]
DRAFT SMTP in Dual Stack Environments May 2004
; if the sender MTA is IPv4-only, email delivery to a.example.org
; should fail with the same error as deliveries to b.example.org.
a.example.org. IN MX 1 mx1.a.example.org.
mx1.a.example.org. IN AAAA 2001:db8:ffff::1 ; IPv6-only
b.example.org. IN MX 1 mx1.b.example.org. ; no address
An algorithm for a dual-stack SMTP sender is as follows:
(1) Lookup the MX record for the destination domain. If a CNAME record
is returned, go to the top of step (1) with replacing the
destination domain by the query's result. If any MX records are
returned, go to step (2) with the query's result (explicit MX). If
NODATA (i.e. empty answer with NOERROR(0) RCODE) is returned,
there is no MX record but the name is valid. Assume that there is
a record like "name. IN MX 0 name." (implicit MX) and go to step
(3). If HOST_NOT_FOUND (i.e. empty answer with NXDOMAIN(3) RCODE)
is returned, there is no such domain. Raise a permanent email
delivery failure. Finish. If SERVFAIL is returned, retry after
certain period of time.
(2) Compare each host name in MX records with the names of sending
host. If there is any match, drop MX records which have equal to
or larger than the value of the lowest-preference matching MX
record (including itself). If multiple MX records remain, sort the
MX records in ascending order based on their preference values.
Loop over steps (3) to (9) on each host name in MX records in a
sequence. If no MX records remain, the sending host must be the
primary MX host. Other routing rule should be applied. Finish.
(3) If the sending MTA has IPv4 capability, lookup the A records. Keep
the resulting addresses until step (5).
(4) If the sending MTA has IPv6 capability, lookup the AAAA records.
NOTE: IPv6 addresses for hosts defined by MX records may be
informed in additional information section of DNS queries' result
as well as IPv4 addresses. If there is no additional address
information for the MX hosts, separate queries for A or AAAA
records should be sent. There is no way to query A and AAAA
records at once in current DNS implementation.
(5) If there is no A and no AAAA record present, try the next MX record
(go to step (3)). Note that the next MX record could have the same
preference.
NOTE: If one or more address records are found, an implementation
may sort addresses based on the implementation's preference of A or
AAAA records. To encourage the transition from IPv4 SMTP to IPv6
SMTP, AAAA records should take precedence. The sorting may only
reorder addresses from MX records of the same preference. RFC2821
section 5 paragraph 4 suggests randomization of destination
addresses. Randomization should only happen among A records, and
NAKAMURA, HAGINO Expires: Novermber 10, 2004 [Page 4]
DRAFT SMTP in Dual Stack Environments May 2004
among AAAA records (do not mix A and AAAA records).
(6) For each of the addresses, loop over steps (7) to (9).
(7) Try to make a TCP connection to the destination's SMTP port (25).
The client needs to follow timeouts documented in RFC2821 section
4.5.3.2. If successful, go to step (9).
(8) If unsuccessful and there is another available address, try the
next available address. Go to step (7). If all addresses are not
reachable and if a list of MX records is being traversed, try the
next MX record (go to step (3)). If there is no list of MX
records, or if the end of the list of MX records has been reached,
raise a temporary email delivery failure. Finish.
(9) Attempt to deliver the e-mail over the connection established, as
specified in RFC2821 [Klensin, 2001] . If a transient failure
condition reported, try the next MX record (go to step (3)). If an
error condition reported, raise a permanent email delivery error,
and further MX records are not tried. Finish. If successful, SMTP
delivery has succeeded. Finish.
4. MX Configuration in the Recipient Domain
4.1. Ensuring Reachability for Both Protocol Versions
If a site has dual-stack reachability, the site should configure both A
and AAAA records for its MX hosts (NOTE: MX hosts can be outside of the
site). This will help both IPv4 and IPv6 senders to reach the site
efficiently.
4.2. Reachability Between the Primary and Secondary MX
When registering MX records in a DNS database in a dual-stack
environment, reachability between MX hosts must be considered carefully.
Suppose all inbound email is to be gathered at the primary MX host,
"mx1.example.org.":
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
IN MX 100 mx100.example.org.
If "mx1.example.org" is an IPv6-only node, and the others are IPv4-only
nodes, there is no reachability between the primary MX host and the
other MX hosts. When email reaches one of the lower MX hosts, it cannot
be relayed to the primary MX host based on MX preferencing mechanism,
therefore mx1.example.org will not be able to collect all the emails
(unless there is another transport mechanism(s) between lower-preference
MX hosts and mx1.example.org).
NAKAMURA, HAGINO Expires: Novermber 10, 2004 [Page 5]
DRAFT SMTP in Dual Stack Environments May 2004
; This configuration is troublesome.
; No secondary MX can reach mx1.example.org.
example.org. IN MX 1 mx1.example.org. ; IPv6-only
IN MX 10 mx10.example.org. ; IPv4-only
IN MX 100 mx100.example.org. ; IPv4-only
The easiest possible configuration is to configure the primary MX host
as a dual-stack node. By doing so, secondary MX hosts will have no
problem reaching the primary MX host.
; This configuration works well.
; The secondary MX hosts are able to relay email to the primary MX host
; without any problems.
example.org. IN MX 1 mx1.example.org. ; dual-stack
IN MX 10 mx10.example.org. ; IPv4-only
IN MX 100 mx100.example.org. ; IPv6-only
It may not be needed that the primary MX host and lower MX hosts reach
directly one another with IPv4 or IPv6 transport. For example, it is
possible to establish a routing path with UUCP or an IPv4/v6 translator.
It is also possible to drop messages into single mailbox with shared
storage using NFS or something else offered by a dual-stack server. It
is receiver site's matter that all messages delivered to each MX hosts
must be reached to recipient's mail drop. In such cases, dual-stack MX
host may not be listed in the MX list.
5. Operational Experience
Many of the existing IPv6-ready MTA's appear to work in the way
documented in section 3.
There were, however, cases where IPv6-ready MTA's were confused by
broken DNS servers. When attempting to obtain a canonical hostname,
some broken name servers return SERVFAIL (RCODE 2), a temporary failure,
on AAAA record lookups. Upon this temporary failure, the email is
queued for a later attempt. In the interest of IPv4/v6
interoperability, these broken DNS servers should be fixed. A draft by
Yasuhiro Morishita [Morishita, 2003] has more detail on
misconfigured/misbehaving DNS servers and their bad sideeffects.
6. Open Issues
o How should scoped addresses (i.e. link-local addresses) in email
addresses be interpreted on MTA's? We suggest prohibiting the use of
IPv6 address literals in destination specification.
o A future specification of SMTP (revision of RFC2821) should be updated
to include IPv6 concerns presented in this memo, such as (1)
additional query of AAAA RRs where A RRs and/or MX RRs are suggested,
and (2) ordering between IPv6 destination and IPv4 destination.
NAKAMURA, HAGINO Expires: Novermber 10, 2004 [Page 6]
DRAFT SMTP in Dual Stack Environments May 2004
7. Security Considerations
It could be problematic if the route-addr email address format [Crocker,
1982] (or "obs-route" address format in [Resnick, 2001] ) is used
across multiple scope zones. MTAs would need to reject email with
route-addr email address formats which crosses scope zone borders.
Appendix A. Considereations on Translators
IPv6-only MTA to IPv4-only MTA case could use help from IPv6-to-IPv4
translators such as [Hagino, 2001] . Normally there are no special SMTP
considerations for translators needed. If there is SMTP traffic from an
IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA
will consider this as a normal IPv4 SMTP traffic.
Protocols like IDENT [St.Johns, 1993] may require special consideration
when translators are used. Also, there are MTAs which perform strict
check on SMTP HELO/EHLO "domain" parameter (perform reverse/forward DNS
lookups and see if the "domain" really associates to the SMTP client's
IP address). In such case we need a special consideration when
translators are used (for instance, override "domain" parameter by
translator's FQDN/address).
Even without a translator, it seems that there are some MTA
implementations in the wild which send IPv6 address literal in HELO/EHLO
message (like "HELO [IPv6:blah]") even when it is using IPv4 trasport,
or vice versa. If the SMTP peer is IPv4-only, it won't understand
"[IPv6:blah]" syntax and mails won't go out of the (broken) MTA. These
implementations have to be corrected.
References
Mokapetris, 1987.
P.V. Mokapetris, "Domain names - implementation and specification" in
RFC1035 (November 1987). ftp://ftp.isi.edu/in-notes/rfc1035.txt.
Thomson, 2003.
S. Thomson, C. Huitema, V. Ksinant, and M. Souissi, "DNS Extensions to
support IP version 6" in RFC3596 (October 2003). ftp://ftp.isi.edu/in-
notes/rfc3596.txt.
Partridge, 1986.
C. Partridge, "Mail routing and the domain system" in RFC974 (January
1986). ftp://ftp.isi.edu/in-notes/rfc974.txt.
Klensin, 2001.
J. Klensin, Editor, "Simple Mail Transfer Protocol" in RFC2821 (April
2001). ftp://ftp.isi.edu/in-notes/rfc2821.txt.
NAKAMURA, HAGINO Expires: Novermber 10, 2004 [Page 7]
DRAFT SMTP in Dual Stack Environments May 2004
Crocker, 1982.
D. Crocker, "Standard for the format of ARPA Internet text messages" in
RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt.
Resnick, 2001.
P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001).
ftp://ftp.isi.edu/in-notes/rfc2822.txt.
Hagino, 2001.
Jun-ichiro Hagino and Hal Snyder, "IPv6 multihoming support at site exit
routers" in RFC3178 (October 2001). ftp://ftp.isi.edu/in-
notes/rfc3178.txt.
St.Johns, 1993.
M. St.Johns, "Identification Protocol" in RFC1413 (January 1993).
ftp://ftp.isi.edu/in-notes/rfc1413.txt.
Informative references
Morishita, 2003.
Y. Morishita and T. Jinmei, "Common Misbehavior against DNS Queries for
IPv6 Addresses" in draft-morishita-dnsop-misbehavior-against-aaaa-00.txt
(June 2003). work in progress material.
Change history
[This section should be removed on publication as an RFC]
draft-ietf-ngtrans-ipv6-smtp-requirement-00 -> 01
Corrected the email address notation for source-routed emails,
based on a comment from Gregory Neil Shapiro.
01 -> 02
Change a reference to refer to RFC2822, not 822. Used
"example.org", not "sample.org". These changes were based on
comments from Arnt Gulbrandsen. Added an ``Operational
experiences'' section. Clarified the case where an MX record
points to a CNAME record, based on comments from Mohsen Souissi.
02 -> 03
In some cases, IPv6-ready MTAs are troubled by incorrect DNS server
responses for AAAA queries. This change was based on comments from
Gregory Neil Shapiro.
03 -> 04
Grammar cleanups by JJ Behrens. More text on the delivery error
cases.
04 -> 05
Change title, suggested by Alain Durand. Limit the scope of the
NAKAMURA, HAGINO Expires: Novermber 10, 2004 [Page 8]
DRAFT SMTP in Dual Stack Environments May 2004
document to dual stack environment (interoperation of IPv6-only
cloud and IPv4-only cloud is out of scope).
05 -> 06
Section on summary of IPv4 MX operation is deleted (Replaced by
Introduction). Clarify on CNAME chain. Cleanups on sender's
algorithm. Suggested by Patrik Faltstrom.
06 -> 07
Site local address is being obsoleted in IPv6 wg, so remove
reference to site-locals. Reflect comments from John C Klensin:
fixes to sending rules, correct route-addr issues. Reflect
comments from Michael A. Patton: HELO on connection via translator.
Reflect comments from Robert Elz.
07 -> 08
Refer a draft by Yasuhiro Morishita.
08 -> draft-motonori-dualstack-smtp-requirement-00
Back to personal submission as suggested by ADs. Many comments
from Dean Strik and Pekka Savola. Split consideration on
translators into Appendix A.
draft-motonori-dualstack-smtp-requirement-00 -> 01
Reflect comments from dean Strik, Pekka Savola and Rob Austein.
Split normative and informative references.
Acknowledgements
This draft was written based on discussions with Japanese IPv6 users and
help from the WIDE research group. Here is a (probably incomplete) list
of people who contributed to the draft: Gregory Neil Shapiro, Arnt
Gulbrandsen, Mohsen Souissi, JJ Behrens, John C Klensin, Michael A.
Patton, Robert Elz, Dean Strik, Pekka Savola, and Rob Austein.
Authors' address
NAKAMURA, HAGINO Expires: Novermber 10, 2004 [Page 9]
DRAFT SMTP in Dual Stack Environments May 2004
Motonori NAKAMURA
Academic Center for Computing and Media Studies, Kyoto University
Yoshida-honmachi, Sakyo, Kyoto 606-8501, JAPAN
Fax: +81-75-753-7450
Email: motonori@media.kyoto-u.ac.jp
Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
1-105, Kanda Jinbo-cho,
Chiyoda-ku,Tokyo 101-0051, JAPAN
Tel: +81-3-5205-6464
Fax: +81-3-5205-6466
Email: itojun@iijlab.net
NAKAMURA, HAGINO Expires: Novermber 10, 2004 [Page 10]