Internet Engineering Task Force                        Motonori Nakamura
INTERNET-DRAFT                                          Kyoto University
Expires: April 24, May 8, 2002                            Jun-ichiro itojun Hagino
                                                 IIJ Research Laboratory
                                                        October 24,
                                                        November 8, 2001

                   IPv6 SMTP operational requirements
            draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt
            draft-ietf-ngtrans-ipv6-smtp-requirement-04.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 April 24, May 8, 2002.

Abstract

The memo

This document lists operational requirements for IPv6 SMTP, SMTP and
IPv6-capable MX DNS records.  As we deploy IPv6 SMTP servers, servers are deployed, it became has
become apparent that
we need certain configuration configurations are necessary in
IPv6-capable MX DNS record, records for stable dual-stack (IPv4 and IPv6) SMTP operations.  The
operation.  This document tries to
clarify clarifies the problems we have that exist in the
transition period between IPv4 SMTP and IPv6 SMTP, and SMTP.  It also defines
operational requirements for stable IPv4/v6 SMTP operation.

The

This document does not try to define any new protocol.

1.  Summary of IPv4 MX operation

For reference purpose, the purposes, this section outlines how mail email message delivery
is performed in an IPv4-only environment [Partridge, 1986] .

DRAFT              IPv6 SMTP operational requirements       October      November 2001

In IPv4 SMTP operation, we register the MX records like below, for record "example.org."  domain: would be registered
as follows:

     example.org.            IN MX   1  mx1.example.org.
                             IN MX   10 mx10.example.org.
     mx1.example.org.        IN A    1.0.0.1    192.0.2.1
     mx10.example.org.       IN A    1.0.0.2    192.0.2.2

When an MTA delivers wishes to deliver a message to a particular destination (say it is to
foo@example.org),
(e.g.  "foo@example.org"), the MTA would send sends DNS queries to lookup DNS database in the following
order:

o Lookup MX record for "example.org.".

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

  o If a CNAME record is returned, try to chase the CNAME chain.
    Eventually we will reach some an A record. record will be reached.

    NOTE: from RFC2181 [Elz, 1997] prohibits MX records must not point from pointing to
    CNAME records [Elz,
    1997] . records.  However, it has been permitted this was not prohibited in older RFCs earlier RFCs.
    [Partridge, 1986] .  We mention CNAME chasing logic is mentioned here just for backward
    backwards compatibility.  Implementers may want to avoid CNAME
    chasing to be
    more conformant to better conform with RFC2181.

  o If the MX lookup failed fails with NO_DATA, it means that there is no MX
    record
    record, but there can may be other record for "example.org.". records (e.g. "example.org.").
    Lookup the A record for "example.org.".

  o If the MX lookup failed fails with HOST_NOT_FOUND, it means that there is
    no record at all for "example.org.".  This means results in a delivery
    failure.

2.  MX records and IPv6 SMTP operation

The following sections talk about explain how to make IPv4 SMTP and IPv6 SMTP
coexist, under
coexist in a dual-stack environment during the transition period between IPv4 to IPv6.
an IPv4-only environment and an IPv6-only environment.  In the future,
when we have completely migrated the migration to an IPv6-only network, we can forget about network is complete, IPv4/v6 SMTP interaction.

As
interaction will be ignored.

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

For simplicity, the this document lists DNS records for IPv6 address addresses as
AAAA records, not as A6 records [Crawford, 2000] .  In reality, we can use a chain
of A6 records, records can be used, instead of AAAA records.

DRAFT              IPv6 SMTP operational requirements      November 2001

There are couple of several technologies defined for the transition from IPv4 and IPv6 transition.
The to
IPv6.  This document concentrates on SMTP issues with dual stack in a dual-stack
environment.
Translators do not need  Afterall, there are no special consideration from SMTP point of view; considerations for
translators; If we have there is SMTP traffic from an IPv6 MTA to an IPv4 MTA
over an IPv6-to-IPv4

DRAFT              IPv6 SMTP operational requirements       October 2001 translator, the traffic IPv4 MTA will be considered as a consider this normal
IPv4 SMTP
traffic, from the IPv4 MTA point of view.  We may, however, need some
consideration on translators for protocols traffic.  Protocols like IDENT [StJohns, 1993] . , however, may
require special consideration when translators are used.

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.

3.  SMTP sender algorithm in dual stack a dual-stack environment

In a dual-stack environment

When we lookup MX records for the a domain in IPv4/v6 dual stack
environment, we will see records like below: resemble the
following:

     example.org.            IN MX   1  mx1.example.org.
                             IN MX   10 mx10.example.org.
     mx1.example.org.        IN A    1.0.0.1    192.0.2.1        ; IPv4/v6 dual stack dual-stack
                             IN AAAA 3ffe:501:ffff::1
     mx10.example.org.       IN AAAA 3ffe:501:ffff::2 ; IPv6 only

For a single MX record, we have record there are many possibility for the possible final lookup
result, states, including:
(a) single, one or multiple more A records for the IPv4 destination, (b) single, one or multiple more AAAA
records for the IPv6 destination, (c) a mixture of A and AAAA records.  As we can define
Because multiple MX records
with may be defined using different preference value, we also need to go through
values, multiple addresses based on multiple MXes.  We need to cope with domains MX's must be traversed.
Domains without MX records, records and failure recovery cases too. must be handled
properly as well.

The algorithm for a an SMTP sender would 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 this. MX
records without address records.

     ; 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  3ffe:501:ffff::1 ; IPv6 only
     b.example.org.          IN MX    1  mx1.b.example.org.
     mx1.b.example.org.      IN HINFO "NO ADDRESS RECORDS"

DRAFT              IPv6 SMTP operational requirements      November 2001

(1)  Lookup the MX record for the destination domain.  If a CNAME record
     is returned, go back to step (1) with the queried query's result.  If any MX
     records are returned, go to step (2) with the query's result.  If
     NO_DATA is returned, go to step (3) as there is no MX record.  Go to step (3).  If
     HOST_NOT_FOUND is returned, there is no domain, raise domain.  Raise a permanent
     email delivery failure (finish). failure.  Finish.

     NOTE: regarding to  the previous section contains a note about MX records pointing that
     point to CNAME records, see a note in
     the previous section. records.

(2)  We have  There are multiple MX records.  Sort the MX records with us.  Loop steps from (3) to (8), in ascending
     order based on MX their preference values, in ascending order. and loop over steps (3) to
     (8).

(3)  If the source sending MTA has IPv4 capability, lookup the A record.  Keep
     the resulting address till until step (5).

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

(5)  Reorder queried  If there is no A or AAAA record present, try the next MX record (go
     to step (3)).  Sort the query's result based on implementation-dependent the
     implementation's preference
     between of A and or AAAA records.  If you would like it is
     desirable to encourage the transition from IPv4 SMTP to IPv6 SMTP, AAAAs
     AAAA records should take precedence.

(6)  Loop steps from (7) to (8), for all  For each of the addresses (or or each part of the list of addresses) we have. addresses,
     loop over steps (7) to (8).  If no reachable destination is found,
     and if we are going through a list of MX records, go back to (3)

DRAFT              IPv6 SMTP operational requirements       October 2001

     and records is being traversed, try the next MX record.
     record (go to step (3)).  If we do not have a there is no list of MX records, or we have reached if
     the end of the list of MX records, records has been reached, raise a
     temporary email delivery failure (finish). failure.  Finish.

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

(8)  Try a an SMTP protocol negotiation.  If the SMTP protocol negotiation
     fails with TEMPFAIL (4xx), go back to (3) and try the next MX
     record. record (go to step (3)).
     If it succeeds, successful, SMTP delivery was successful (finish). has succeeded.  Finish.

4.  MX configuration in receipient the recipient domain

4.1.  Ensuring reachability for both protocol versions

If a site has IPv4/v6 dual stack dual-stack reachability, the site SHOULD configure both A
and AAAA records onto for its MX hosts.  It  This will help both IPv4 and IPv6
senders to reach the site efficienlty. efficiently.

4.2.  Reachability between the primary and secondary MX

When we configure entering MX records onto in a DNS database in a dual-stack environment, we need to be careful about
reachability between MX hosts. hosts must be considered carefully.  Suppose we try to gather all

DRAFT              IPv6 SMTP operational requirements      November 2001

inbound email is to be gathered at the primary MX host,
mx1.example.org.
"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 "mx1.example.org" is an IPv6 only node IPv6-only node, and the rest others are IPv4 only node,
we have IPv4-only
nodes, there is no reachability between the primary MX host and the rest.  Once an
other MX hosts.  When email reaches one of the secondary MX host, the email will never reach hosts, it
cannot be relayed to the primary MX. MX host.

     ; the This configuration is troublesome.
     ; no 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 an IPv4/v6 dual stack a dual-stack node.  By doing so, secondaries secondary MX hosts will have no
problem reaching the primary MX host.

     ; the This configuration works just fine. well.
     ; emails reaches from The secondary MX hosts are able to relay email to the primary with no trouble. MX host
     ; without any problems.
     example.org.    IN MX   1   mx1.example.org.     ; IPv4/v6 dual stack dual-stack
                     IN MX   10  mx10.example.org.    ; IPv4 only
                     IN MX   100 mx100.example.org.   ; IPv6 only

DRAFT              IPv6 SMTP operational requirements       October 2001

There are many other ways to ensure that the reachability between secondary primary MX host and primary MX. the
secondary MX hosts can reach one another.  For example, we could it is possible
to configure the secondary MX hosts to route emails email statically, i.e.
without considering the DNS MX configuration.  Or
we could estalish alternative  It is also possible to
establish an alternate email routing path (i.e. UUCP, (e.g. UUCP or via an IPv4/v6
translator) between the secondary MX host and the primary MX. MX host.

5.  Operational experiences experience

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

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

There were, however, cases where IPv6-ready MTAs get MTA's were confused by
broken DNS servers.  When attempting to canonify a hostname, some broken
name servers will return SERVFAIL (a SERVFAIL, a temporary failure) failure, on AAAA record
lookups.  Upon this temporary failure, the mail email is queued up for a later
attempt.  These  In the interest of IPv4/v6 interoperability, these broken DNS

DRAFT              IPv6 SMTP operational requirements      November 2001

servers should get fixed, for this issue as
well as for other IPv6 operations. be fixed.

6.  Open issues

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

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

                 <@kame.net,@[fec0::1]:itojun@itojun.org>

  it gets more even trickier.  Luckily, the route-addr form was obsoleted by
  RFC2822 [Resnick, 2001] .

7.  Security consideration considerations

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

DRAFT              IPv6 SMTP operational requirements       October 2001

References

Partridge, 1986.
C. Partridge, "Mail routing and the domain system" in RFC974 (January
1986). ftp://ftp.isi.edu/in-notes/rfc974.txt.

Elz, 1997.
R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181
(July 1997). ftp://ftp.isi.edu/in-notes/rfc2181.txt.

Thomson, 1995.
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.

Crawford, 2000.
M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering" in RFC2874 (July 2000).
ftp://ftp.isi.edu/in-notes/rfc2874.txt.

StJohns, 1993.
M. StJohns, "Identification Protocol" in RFC1413 (January 1993).

DRAFT              IPv6 SMTP operational requirements      November 2001

ftp://ftp.isi.edu/in-notes/rfc1413.txt.

Klensin, 2001.
J. Klensin, Editor, "Simple Mail Transfer Protocol" in RFC2821 (April
2001). ftp://ftp.isi.edu/in-notes/rfc2821.txt.

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.

Change history

00 -> 01
     Correct
     Corrected the email address notation for source-routed emails,
     based on a comment from Gregory Neil Shapiro.

01 -> 02
     Refer
     Change a reference to refer to RFC2822, not 822.  Use example.org,  Used
     "example.org", not sample.org.  Based "sample.org".  These changes were based on
     comments from Arnt Gulbrandse.  Add Operational experiences Gulbrandsen.  Added an ``Operational
     experiences'' section.  Clarify MX-points-to-CNAME,  Clarified the case where an MX record
     points to a CNAME record, based on comments from Mohsen Souissi.

02 -> 03
     Some
     In some cases, IPv6-ready MTAs gets MTA's are troubled by wrong incorrect DNS
     server responses for AAAA queries.  From  This change was based on
     comments from Gregory Neil Shapiro.

DRAFT              IPv6 SMTP operational requirements       October 2001

03 -> 04
     Grammar cleanups by JJ Behrens.  More text on the delivery error
     cases.

Acknowledgements

The

This draft was written based on discussions with Japanese IPv6 users, users and
help from the WIDE research group.  Here are is a (probably incomplete) list
of people who contributed to the draft: Gregory Neil Shapiro, Arnt Gulbrandse,
and
Gulbrandsen, Mohsen Souissi. Souissi, and JJ Behrens.

Author's address

DRAFT              IPv6 SMTP operational requirements      November 2001

     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
     Email: motonori@media.kyoto-u.ac.jp

     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
     Email: itojun@iijlab.net