draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt   draft-ietf-ngtrans-ipv6-smtp-requirement-05.txt 
Internet Engineering Task Force Motonori Nakamura Internet Engineering Task Force Motonori Nakamura
INTERNET-DRAFT Kyoto University INTERNET-DRAFT Kyoto University
Expires: May 8, 2002 Jun-ichiro itojun Hagino Expires: August 28, 2002 Jun-ichiro itojun Hagino
IIJ Research Laboratory IIJ Research Laboratory
November 8, 2001 February 28, 2002
IPv6 SMTP operational requirements SMTP operational experience in mixed IPv4/IPv6 environements
draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt draft-ietf-ngtrans-ipv6-smtp-requirement-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.'' or to cite them other than as ``work in progress.''
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration will The internet-draft will expire in 6 months. The date of expiration will
be May 8, 2002. be August 28, 2002.
Abstract Abstract
This document lists operational requirements for IPv6 SMTP and This document talks about SMTP operational experiences in IPv4/v6 dual
IPv6-capable MX DNS records. As IPv6 SMTP servers are deployed, it has stack environments. As IPv6-capable SMTP servers are deployed, it has
become apparent that certain configurations are necessary in become apparent that certain configurations are necessary in
IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP
operation. This document clarifies the problems that exist in the operation. This document clarifies the problems that exist in the
transition period between IPv4 SMTP and IPv6 SMTP. It also defines transition period between IPv4 SMTP and IPv6 SMTP. It also defines
operational requirements for stable IPv4/v6 SMTP operation. operational requirements for stable IPv4/v6 SMTP operation.
This document does not define any new protocol. This document does not define any new protocol.
1. Summary of IPv4 MX operation 1. Summary of IPv4 MX operation
For reference purposes, this section outlines how email message delivery For reference purposes, this section outlines how email message delivery
is performed in an IPv4-only environment [Partridge, 1986] . is performed in an IPv4-only environment [Partridge, 1986] .
DRAFT IPv6 SMTP operational requirements November 2001 DRAFT SMTP in dual stack environments February 2002
In IPv4 SMTP operation, the MX record "example.org." would be registered In IPv4 SMTP operation, the MX record "example.org." would be registered
as follows: as follows:
example.org. IN MX 1 mx1.example.org. example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org. IN MX 10 mx10.example.org.
mx1.example.org. IN A 192.0.2.1 mx1.example.org. IN A 192.0.2.1
mx10.example.org. IN A 192.0.2.2 mx10.example.org. IN A 192.0.2.2
When an MTA wishes to deliver a message to a particular destination When an MTA wishes to deliver a message to a particular destination
skipping to change at page 2, line 41 skipping to change at page 2, line 41
chasing to better conform with RFC2181. chasing to better conform with RFC2181.
o If the MX lookup fails with NO_DATA, it means that there is no MX o If the MX lookup fails with NO_DATA, it means that there is no MX
record, but there may be other records (e.g. "example.org."). record, but there may be other records (e.g. "example.org.").
Lookup the A record for "example.org.". Lookup the A record for "example.org.".
o If the MX lookup fails with HOST_NOT_FOUND, it means that there is o If the MX lookup fails with HOST_NOT_FOUND, it means that there is
no record at all for "example.org.". This results in a delivery no record at all for "example.org.". This results in a delivery
failure. failure.
2. MX records and IPv6 SMTP operation 2. MX records and dual stack SMTP operation
The following sections explain how to make IPv4 SMTP and IPv6 SMTP The following sections explain how to make IPv4 SMTP and IPv6 SMTP
coexist in a dual-stack environment during the transition period between coexist in a dual-stack environment.
an IPv4-only environment and an IPv6-only environment. In the future,
when the migration to an IPv6-only network is complete, IPv4/v6 SMTP
interaction will be ignored.
Similar to the way RFC's for IPv6 DNS lookup [Thomson, 1995; Crawford, 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 2000] use IN class for both IPv4 and IPv6, IN MX records will be used
for both IPv4 and IPv6. for both IPv4 and IPv6.
For simplicity, this document lists DNS records for IPv6 addresses as
AAAA records, not as A6 records [Crawford, 2000] . In reality, a chain
of A6 records can be used, instead of AAAA records.
DRAFT IPv6 SMTP operational requirements November 2001
There are several technologies defined for the transition from IPv4 to There are several technologies defined for the transition from IPv4 to
IPv6. This document concentrates on SMTP issues in a dual-stack IPv6. This document concentrates on SMTP issues in a dual-stack
environment. Afterall, there are no special SMTP considerations for environment. Afterall, there are no special SMTP considerations for
translators; If there is SMTP traffic from an IPv6 MTA to an IPv4 MTA 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 over an IPv6-to-IPv4 translator, the IPv4 MTA will consider this normal
IPv4 SMTP traffic. Protocols like IDENT [StJohns, 1993] , however, may IPv4 SMTP traffic. Protocols like IDENT [StJohns, 1993] , however, may
require special consideration when translators are used. require special consideration when translators are used.
DRAFT SMTP in dual stack environments February 2002
This document does not discuss the problems encountered when the sending 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 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 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 should be resolved by making either side dual-stack or by making either
side use a protocol translator. side use a protocol translator.
3. SMTP sender algorithm in a dual-stack environment 3. SMTP sender algorithm in a dual-stack environment
In a dual-stack environment MX records for a domain resemble the In a dual-stack environment MX records for a domain resemble the
following: following:
skipping to change at page 4, line 5 skipping to change at page 3, line 48
are no A records available) the case should be treated just like MX are no A records available) the case should be treated just like MX
records without address records. records without address records.
; if the sender MTA is IPv4 only, email delivery to a.example.org ; 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. ; should fail with the same error as deliveries to b.example.org.
a.example.org. IN MX 1 mx1.a.example.org. a.example.org. IN MX 1 mx1.a.example.org.
mx1.a.example.org. IN AAAA 3ffe:501:ffff::1 ; IPv6 only mx1.a.example.org. IN AAAA 3ffe:501:ffff::1 ; IPv6 only
b.example.org. IN MX 1 mx1.b.example.org. b.example.org. IN MX 1 mx1.b.example.org.
mx1.b.example.org. IN HINFO "NO ADDRESS RECORDS" 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 (1) Lookup the MX record for the destination domain. If a CNAME record
is returned, go to step (1) with the query's result. If any MX is returned, go to step (1) with the query's result. If any MX
records are returned, go to step (2) with the query's result. If records are returned, go to step (2) with the query's result. If
NO_DATA is returned, there is no MX record. Go to step (3). If NO_DATA is returned, there is no MX record. Go to step (3). If
HOST_NOT_FOUND is returned, there is no domain. Raise a permanent HOST_NOT_FOUND is returned, there is no domain. Raise a permanent
email delivery failure. Finish. email delivery failure. Finish.
NOTE: the previous section contains a note about MX records that NOTE: the previous section contains a note about MX records that
point to CNAME records. point to CNAME records.
DRAFT SMTP in dual stack environments February 2002
(2) There are multiple MX records. Sort the MX records in ascending (2) There are multiple MX records. Sort the MX records in ascending
order based on their preference values, and loop over steps (3) to order based on their preference values, and loop over steps (3) to
(8). (8).
(3) If the sending MTA has IPv4 capability, lookup the A record. Keep (3) If the sending MTA has IPv4 capability, lookup the A record. Keep
the resulting address until step (5). the resulting address until step (5).
(4) If the sending MTA has IPv6 capability, lookup the AAAA record. (4) If the sending MTA has IPv6 capability, lookup the AAAA record.
(5) If there is no A or AAAA record present, try the next MX record (go (5) If there is no A or AAAA record present, try the next MX record (go
skipping to change at page 5, line 4 skipping to change at page 4, line 48
4.1. Ensuring reachability for both protocol versions 4.1. Ensuring reachability for both protocol versions
If a site has dual-stack reachability, the site SHOULD configure both A 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 and AAAA records for its MX hosts. This will help both IPv4 and IPv6
senders to reach the site efficiently. senders to reach the site efficiently.
4.2. Reachability between the primary and secondary MX 4.2. Reachability between the primary and secondary MX
When entering MX records in a DNS database in a dual-stack environment, When entering MX records in a DNS database in a dual-stack environment,
reachability between MX hosts must be considered carefully. Suppose all reachability between MX hosts must be considered carefully. Suppose all
DRAFT IPv6 SMTP operational requirements November 2001
inbound email is to be gathered at the primary MX host, 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. example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org. IN MX 10 mx10.example.org.
IN MX 100 mx100.example.org. IN MX 100 mx100.example.org.
If "mx1.example.org" is an IPv6-only node, and the others are IPv4-only 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 nodes, there is no reachability between the primary MX host and the
other MX hosts. When email reaches one of the secondary MX hosts, it other MX hosts. When email reaches one of the secondary MX hosts, it
DRAFT SMTP in dual stack environments February 2002
cannot be relayed to the primary MX host. cannot be relayed to the primary MX host.
; This configuration is troublesome. ; This configuration is troublesome.
; No secondary MX can reach mx1.example.org. ; No secondary MX can reach mx1.example.org.
example.org. IN MX 1 mx1.example.org. ; IPv6 only example.org. IN MX 1 mx1.example.org. ; IPv6 only
IN MX 10 mx10.example.org. ; IPv4 only IN MX 10 mx10.example.org. ; IPv4 only
IN MX 100 mx100.example.org. ; IPv4 only IN MX 100 mx100.example.org. ; IPv4 only
The easiest possible configuration is to configure the primary MX host 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 as a dual-stack node. By doing so, secondary MX hosts will have no
skipping to change at page 6, line 4 skipping to change at page 5, line 48
>From past experiments and operational experience, it is known that most >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 of the existing IPv4-only MTA's will not be confused by AAAA records
that are registered for MX hostnames. No experiments were conducted that are registered for MX hostnames. No experiments were conducted
with A6 records. with A6 records.
There were, however, cases where IPv6-ready MTA's were confused by There were, however, cases where IPv6-ready MTA's were confused by
broken DNS servers. When attempting to canonify a hostname, some broken broken DNS servers. When attempting to canonify a hostname, some broken
name servers return SERVFAIL, a temporary failure, on AAAA record name servers return SERVFAIL, a temporary failure, on AAAA record
lookups. Upon this temporary failure, the email is queued for a later lookups. Upon this temporary failure, the email is queued for a later
attempt. In the interest of IPv4/v6 interoperability, these broken DNS attempt. In the interest of IPv4/v6 interoperability, these broken DNS
DRAFT IPv6 SMTP operational requirements November 2001
servers should be fixed. servers should be fixed.
6. Open issues 6. Open issues
o How should scoped addresses in email addresses be interpreted on o How should scoped addresses in email addresses be interpreted on
MTA's? As email is relayed between MTA's, interpretation of scoped MTA's? As email is relayed between MTA's, interpretation of scoped
addresses can be different between MTA's. Afterall, intermediate addresses can be different between MTA's. Afterall, intermediate
MTA's may be in different scope zones than the originator. If a 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 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? should MTA's behave?
If scoped addresses in ``route-addr'' specifications [Crocker, 1982] If scoped addresses in ``route-addr'' specifications [Crocker, 1982]
are considered, e.g. are considered, e.g.
<@kame.net,@[fec0::1]:itojun@itojun.org> <@kame.net,@[fec0::1]:itojun@itojun.org>
it gets even trickier. Luckily, the route-addr form was obsoleted by it gets even trickier. Luckily, the route-addr form was obsoleted by
RFC2822 [Resnick, 2001] . RFC2822 [Resnick, 2001] .
skipping to change at page 7, line 4 skipping to change at page 6, line 47
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt. RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.
Crawford, 2000. Crawford, 2000.
M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6 M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering" in RFC2874 (July 2000). Address Aggregation and Renumbering" in RFC2874 (July 2000).
ftp://ftp.isi.edu/in-notes/rfc2874.txt. ftp://ftp.isi.edu/in-notes/rfc2874.txt.
StJohns, 1993. StJohns, 1993.
M. StJohns, "Identification Protocol" in RFC1413 (January 1993). M. StJohns, "Identification Protocol" in RFC1413 (January 1993).
DRAFT IPv6 SMTP operational requirements November 2001
ftp://ftp.isi.edu/in-notes/rfc1413.txt. ftp://ftp.isi.edu/in-notes/rfc1413.txt.
Klensin, 2001. Klensin, 2001.
J. Klensin, Editor, "Simple Mail Transfer Protocol" in RFC2821 (April J. Klensin, Editor, "Simple Mail Transfer Protocol" in RFC2821 (April
2001). ftp://ftp.isi.edu/in-notes/rfc2821.txt. 2001). ftp://ftp.isi.edu/in-notes/rfc2821.txt.
Crocker, 1982. Crocker, 1982.
D. Crocker, "Standard for the format of ARPA Internet text messages" in D. Crocker, "Standard for the format of ARPA Internet text messages" in
RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt. RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt.
DRAFT SMTP in dual stack environments February 2002
Resnick, 2001. Resnick, 2001.
P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001). P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001).
ftp://ftp.isi.edu/in-notes/rfc2822.txt. ftp://ftp.isi.edu/in-notes/rfc2822.txt.
Change history Change history
00 -> 01 00 -> 01
Corrected the email address notation for source-routed emails, Corrected the email address notation for source-routed emails,
based on a comment from Gregory Neil Shapiro. based on a comment from Gregory Neil Shapiro.
skipping to change at page 7, line 43 skipping to change at page 7, line 33
02 -> 03 02 -> 03
In some cases, IPv6-ready MTA's are troubled by incorrect DNS In some cases, IPv6-ready MTA's are troubled by incorrect DNS
server responses for AAAA queries. This change was based on server responses for AAAA queries. This change was based on
comments from Gregory Neil Shapiro. comments from Gregory Neil Shapiro.
03 -> 04 03 -> 04
Grammar cleanups by JJ Behrens. More text on the delivery error Grammar cleanups by JJ Behrens. More text on the delivery error
cases. cases.
04 -> 05
Change title, suggested by Alain Durand.
Acknowledgements Acknowledgements
This draft was written based on discussions with Japanese IPv6 users and This draft was written based on discussions with Japanese IPv6 users and
help from the WIDE research group. Here is a (probably incomplete) list help from the WIDE research group. Here is a (probably incomplete) list
of people who contributed to the draft: Gregory Neil Shapiro, Arnt of people who contributed to the draft: Gregory Neil Shapiro, Arnt
Gulbrandsen, Mohsen Souissi, and JJ Behrens. Gulbrandsen, Mohsen Souissi, and JJ Behrens.
Author's address Author's address
DRAFT IPv6 SMTP operational requirements November 2001 DRAFT SMTP in dual stack environments February 2002
Motonori NAKAMURA Motonori NAKAMURA
Center for Information and Multimedia Studies, Kyoto University Center for Information and Multimedia Studies, Kyoto University
Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN
Tel: +81-75-753-9063 Tel: +81-75-753-9063
Fax: +81-75-753-9056 Fax: +81-75-753-9056
Email: motonori@media.kyoto-u.ac.jp Email: motonori@media.kyoto-u.ac.jp
Jun-ichiro itojun HAGINO Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc. Research Laboratory, Internet Initiative Japan Inc.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/