Internet Engineering Task Force                        Motonori Nakamura
INTERNET-DRAFT                                          Kyoto University
Expires: August December 28, 2002                      Jun-ichiro itojun Hagino
                                                 IIJ Research Laboratory
                                                           June 28, 2002

      SMTP operational experience in mixed IPv4/IPv6 environements

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

Distribution of this memo is unlimited.

The internet-draft will expire in 6 months.  The date of expiration will
be August December 28, 2002.


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 are necessary in
IPv6-capable MX DNS records 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.

1.  Summary  Introduction

Deliveries of IPv4 MX operation

For reference purposes, this section outlines how email message delivery mail messages to the final mail drop is performed in an IPv4-only environment [Partridge, 1986] . not always done by
direct IP communication with submiter and final receiver, and there may
be some intermediate hosts to relay the messages.  So it is difficult to

DRAFT                SMTP in dual stack environments       February           June 2002

In IPv4 SMTP operation, the MX record "" would be registered
as follows:            IN MX   1
                             IN MX   10        IN A       IN A

When an MTA wishes to deliver a

know at message to a particular destination
(e.g.  ""), the MTA sends DNS queries in the following

o Lookup MX record for "".

  o If an MX record is returned, lookup an A record for the right-hand
    side of the MX record.

  o If a CNAME record submission (also at receiver side) that all intermediate
relay hosts are properly configured.  It is returned, try to chase the CNAME chain.
    Eventually an A record will be reached.

    NOTE: RFC2181 [Elz, 1997] prohibits MX records from pointing to
    CNAME records.  However, this was not prohibited in earlier RFCs.
    [Partridge, 1986] CNAME chasing logic is mentioned here just for
    backwards compatibility.  Implementers may want to avoid CNAME
    chasing so easy to better conform with RFC2181.

  o If configure all
the MX lookup fails system with NO_DATA, it means that there consistency since mail message delivery system is no MX
    record, but there may be rather
complex on DNS setting than other records (e.g. "").
    Lookup the A record for "".

  o If Internet services.  For the MX lookup fails with HOST_NOT_FOUND, it means that there is
    no record at all for "".  This results in a delivery

2.  MX records and dual stack SMTP operation

The following sections explain how to make transition
state from IPv4 SMTP and IPv6 SMTP
coexist in a dual-stack environment.

Similar to the way RFC's for IPv6 DNS lookup [Thomson, 1995; Crawford,
2000] use IN class for both IPv4 and IPv6, IN MX records will be used
for both IPv4 and IPv6. IPv6 interoperability should be
kept more carefully.

There are several technologies defined for the transition from IPv4 to
IPv6.  This document concentrates on SMTP issues in a dual-stack
environment.  Afterall, there are no special SMTP considerations for
translators; 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 normal
IPv4 SMTP traffic.  Protocols like IDENT [StJohns, [Johns, 1993] , however, may
require special consideration when translators are used.


The following sections explain how to make IPv4 SMTP and IPv6 SMTP
coexist in dual stack environments       February 2002 a dual-stack environment.

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
should be resolved by making either side dual-stack or by making either
side use a protocol translator.

2.  Basic DNS resource record definitions for mail routing

Mail messages on the Internet are delivered based on domain name system
generally.  MX RRs are looked up to know destination hosts associated
with domain part of a mail addresse.  Similar to the way RFC's for IPv6
DNS lookup [Thomson, 1995] use IN class for both IPv4 and IPv6, IN MX
records will be used for both IPv4 and IPv6 on mail message routing,
hosts which have IPv6 transport and want to be delivered with the IPv6
transport must define IPv6 IP addresses for the host name as well as
IPv4 IP addresses.

A MX RR have two data, a preference value and the name of destination
host.  IP addresses for the destination host are also looked up to make
SMTP transport [Partridge, 1986] .  In IPv4 environment, IPv4 IP
addresses are defined with A RRs.

For example, IPv6 only site may have the following DNS definitions:            IN MX   1
                             IN MX   10        IN AAAA 3ffe:501:ffff::1       IN AAAA 3ffe:501:ffff::2

In transition period from IPv4 to IPv6, there are many IPv4 sites, and
such sites will not have mail interoperability with IPv6 only sites.
For the transition period, every IPv6 sites should have both transport
for each domain part of mail addresses, e.g, for example:

DRAFT                SMTP in dual stack environments           June 2002            IN MX   1
                             IN MX   10        IN AAAA 3ffe:501:ffff::1
                             IN A       IN AAAA 3ffe:501:ffff::2
                             IN A

But, every host may not support dual stack operation, some host entries
may have only IPv4 or IPv6 RRs:            IN MX   1
                             IN MX   10        IN AAAA 3ffe:501:ffff::1       IN A

In the following sections, how sender side operates with IPv4/IPv6
combined RR definitions (section 3), and how receiver side should define
RRs to keep interoperability with both IPv4 and IPv6 Internet (section
4) are considerd.

3.  SMTP sender algorithm in a dual-stack environment

In a dual-stack environment MX records for a domain resemble the
following:            IN MX   1
                             IN MX   10        IN A        ; dual-stack
                             IN AAAA 3ffe:501:ffff::1       IN AAAA 3ffe:501:ffff::2 ; IPv6 only

For a single MX record there are many 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 an 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 reachable destionation
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 never fail because of no
known address if other addresses are available related to other MX

DRAFT                SMTP in dual stack environments           June 2002

     ; if the sender MTA is IPv4 only, email delivery to
     ; should fail with the same error as deliveries to          IN MX    1      IN AAAA  3ffe:501:ffff::1 ; IPv6 only          IN MX    1      IN HINFO "NO ADDRESS RECORDS"

An algorithm for SMTP sender in a dual-stack environment 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. result (Implicit MX).  If
     NO_DATA (i.e.  empty answer with NOERROR(0) RCODE) is returned,
     there is no MX record. record but other records (e.g. SOA, NS or A etc.)
     may be found.  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.

     NOTE: Some guard mechanism must required to break circular CNAME

(2)  Compare each host name in MX records with the previous section contains name of sending host.
     If there is a note about record which has the same name, drop MX records that
     point which
     have equal to CNAME records.

DRAFT                SMTP in dual stack environments       February 2002

(2)  There are or larger than preference value of the matched MX
     record (including itself).  If multiple MX records.  Sort records remain, sort the
     MX records in ascending order based on their preference values, and loop values.
     Loop over steps (3) to
     (8). (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 record.  Keep
     the resulting address until step (5).

(4)  If the sending MTA has IPv6 capability, lookup the AAAA record.

     NOTE: IPv6 addresses for hosts defined by MX records may be
     informed in additional information section of DNS querie's 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 or AAAA record present, try the next MX record (go
     to step (3)).  Sort the query's result

     NOTE: If one or more address records are found, some MTA
     implementation may sort addresses  based on the implementation's
     preference of A or AAAA records.  If it is
     desirable to  To encourage the transition from
     IPv4 SMTP to IPv6 SMTP, AAAA records should take precedence.  But
     this type of sorting is optional.

DRAFT                SMTP in dual stack environments           June 2002

(6)  For each of the addresses or each part of the list of addresses, loop over steps (7) to (8). (9).

(7)  Try to make a TCP connection to the destination.  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 no all addresses are not
     reachable destination is found, 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.

(7)  Try to make a TCP connection to the destination.  If unsuccessful,
     try the next available address.  If successful, go to step (8).


(9)  Try an SMTP protocol negotiation.  If the SMTP protocol negotiation
     fails with TEMPFAIL (4xx), according to RFC2821 [Klensin,
     2001] .  If a transient failure condision 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.

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.  This will help both IPv4 and IPv6
senders to reach the site efficiently.

4.2.  Reachability between the primary and secondary MX

When entering 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,
"":    IN MX   1
                     IN MX   10
                     IN MX   100

If "" 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 secondary lower MX hosts, it

DRAFT                SMTP in dual stack environments       February 2002 cannot
be relayed to the primary MX host. host based on MX preferencing mechanism.

     ; This configuration is troublesome.
     ; No secondary MX can reach    IN MX   1     ; IPv6 only
                     IN MX   10    ; IPv4 only
                     IN MX   100   ; 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

DRAFT                SMTP in dual stack environments           June 2002

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.    IN MX   1     ; dual-stack
                     IN MX   10    ; IPv4 only
                     IN MX   100   ; IPv6 only

There are many other ways to ensure

It may not be needed that the primary MX host and the
secondary lower MX hosts can reach
directly one another. another with IPv4 or IPv6 transport.  For example, it is
possible to configure the secondary MX hosts to route email statically, i.e.
without considering the DNS MX configuration.  It is also possible to establish an alternate email a routing path (e.g. with UUCP or an IPv4/v6
translator) between the secondary 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 and may not be listed in the primary MX host. list.

5.  Operational experience

Many of the existing IPv6-ready MTA's appear to work in the way
documented in section 3.

>From past experiments and operational experience, it is known that most
of the existing IPv4-only MTA's will not be confused by AAAA records
that are registered for MX hostnames.  No experiments were conducted
with A6 records.

There were, however, cases where IPv6-ready MTA's were confused by
broken DNS servers.  When attempting to canonify a hostname, some broken
name servers return SERVFAIL, 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.

6.  Open issues

o How should scoped addresses in email addresses be interpreted on
  MTA's?  As email is relayed between MTA's, interpretation of scoped
  addresses can be different between MTA's.  Afterall, intermediate
  MTA's may be in different scope zones than the originator.  If a
  scoped IPv6 address is returned as the result of a DNS lookup, how

DRAFT                SMTP in dual stack environments       February 2002
  should MTA's behave?

  If scoped addresses in ``route-addr'' specifications  [Crocker, 1982]
  are considered, e.g.


  it gets even trickier.  Luckily, the route-addr form was obsoleted by

DRAFT                SMTP in dual stack environments           June 2002

  RFC2822 [Resnick, 2001] .

7.  Security considerations

As mentioned in the ``Open issues'' section, it could be problematic if
the route-addr email address format is used across multiple scope zones.
MTA's would need to reject email with improper route-addr email address
formats.  One example of an improper route-addr format is an email from
outside the site border which carries a numeric site-local address in
the route-addr format.


Partridge, 1986.
C. Partridge, "Mail routing and the domain system"

Johns, 1993.
M. St. Johns, "Identification Protocol" in RFC974 RFC1413 (January

Elz, 1997.
R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181
(July 1997). 1993).

Thomson, 1995.
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
RFC1886 (December 1995).

Crawford, 2000.
M. Crawford,

Partridge, 1986.
C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
Address Aggregation Partridge, "Mail routing and Renumbering" in RFC2874 (July 2000).

StJohns, 1993.
M. StJohns, "Identification Protocol" the domain system" in RFC1413 RFC974 (January 1993).

Klensin, 2001.
J. Klensin, Editor, "Simple Mail Transfer Protocol" in RFC2821 (April

Crocker, 1982.
D. Crocker, "Standard for the format of ARPA Internet text messages" in
RFC822 (August 1982).

DRAFT                SMTP in dual stack environments       February 2002

Resnick, 2001.
P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001).

Change history

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
     "", not "".  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.

DRAFT                SMTP in dual stack environments           June 2002

02 -> 03
     In some cases, IPv6-ready MTA's 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

04 -> 05
     Change title, suggested by Alain Durand.

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.


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, and JJ Behrens.

Author's address

DRAFT                SMTP in dual stack environments       February 2002

     Motonori NAKAMURA
     Center for Information and Multimedia Studies, Kyoto University
     Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN
     Tel: +81-75-753-9063
     Fax: +81-75-753-9056

     Jun-ichiro itojun HAGINO
     Research Laboratory, Internet Initiative Japan Inc.
     Takebashi Yasuda Bldg.,
     3-13 Kanda Nishiki-cho,
     Chiyoda-ku,Tokyo 101-0054, JAPAN
     Tel: +81-3-5259-6350
     Fax: +81-3-5259-6351