draft-ietf-ngtrans-ipv6-smtp-requirement-00.txt   draft-ietf-ngtrans-ipv6-smtp-requirement-01.txt 
Internet Engineering Task Force Motonori Nakamura Internet Engineering Task Force Motonori Nakamura
INTERNET-DRAFT Kyoto University INTERNET-DRAFT Kyoto University
Expires: October 11, 2001 Jun-ichiro itojun Hagino Expires: January 5, 2002 Jun-ichiro itojun Hagino
IIJ Research Laboratory IIJ Research Laboratory
April 11, 2001 July 5, 2001
IPv6 SMTP operational requirements IPv6 SMTP operational requirements
draft-ietf-ngtrans-ipv6-smtp-requirement-00.txt draft-ietf-ngtrans-ipv6-smtp-requirement-01.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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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.''
The list of current Internet-Drafts can be accessed at To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
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 October 11, 2001. be January 5, 2002.
Abstract Abstract
The memo lists operational requirements for IPv6 SMTP, and IPv6-capable The memo lists operational requirements for IPv6 SMTP, and IPv6-capable
MX DNS records. As we deploy IPv6 SMTP servers, it became apparent that MX DNS records. As we deploy IPv6 SMTP servers, it became apparent that
we need certain configuration in IPv6-capable MX DNS record, for stable we need certain configuration in IPv6-capable MX DNS record, for stable
dual-stack (IPv4 and IPv6) SMTP operations. The document tries to dual-stack (IPv4 and IPv6) SMTP operations. The document tries to
clarify the problems we have in transition period between IPv4 SMTP and clarify the problems we have in transition period between IPv4 SMTP and
IPv6 SMTP, and operational requirements for stable IPv4/v6 SMTP IPv6 SMTP, and operational requirements for stable IPv4/v6 SMTP
operation. operation.
The document does not try to define any new protocol. The document does not try to define any new protocol.
1. Summary of IPv4 MX operation 1. Summary of IPv4 MX operation
For reference purpose, the section outlines how mail message delivery is For reference purpose, the section outlines how mail message delivery is
performed in IPv4-only environment [Partridge, 1986] . performed in IPv4-only environment [Partridge, 1986] .
DRAFT IPv6 SMTP operational requirements April 2001 DRAFT IPv6 SMTP operational requirements July 2001
In IPv4 SMTP operation, we register MX records like below, for In IPv4 SMTP operation, we register MX records like below, for
"sample.org." domain: "sample.org." domain:
sample.org. IN MX 1 mx1.sample.org. sample.org. IN MX 1 mx1.sample.org.
IN MX 10 mx10.sample.org. IN MX 10 mx10.sample.org.
mx1.sample.org. IN A 1.0.0.1 mx1.sample.org. IN A 1.0.0.1
mx10.sample.org. IN A 1.0.0.2 mx10.sample.org. IN A 1.0.0.2
When an MTA delivers a message to a particular destination (say it is to When an MTA delivers a message to a particular destination (say it is to
skipping to change at page 3, line 5 skipping to change at page 3, line 5
chain of A6 records, instead of AAAA records. chain of A6 records, instead of AAAA records.
There are couple of technologies defined for IPv4 and IPv6 transition. There are couple of technologies defined for IPv4 and IPv6 transition.
The document concentrates on issues with dual stack environment. The document concentrates on issues with dual stack environment.
Translators do not need special consideration from SMTP point of view; Translators do not need special consideration from SMTP point of view;
If we have SMTP traffic from IPv6 MTA to IPv4 MTA over an IPv6-to-IPv4 If we have SMTP traffic from IPv6 MTA to IPv4 MTA over an IPv6-to-IPv4
translator, the traffic will be considered as a normal IPv4 SMTP translator, the traffic will be considered as a normal IPv4 SMTP
traffic, from the IPv4 MTA point of view. We may, however, need some traffic, from the IPv4 MTA point of view. We may, however, need some
consideration on translators for protocols like IDENT [StJohns, 1993] . consideration on translators for protocols like IDENT [StJohns, 1993] .
DRAFT IPv6 SMTP operational requirements April 2001 DRAFT IPv6 SMTP operational requirements July 2001
3. SMTP sender algorithm in dual stack environment 3. SMTP sender algorithm in dual stack environment
When we lookup MX records for the domain in IPv4/v6 dual stack When we lookup MX records for the domain in IPv4/v6 dual stack
environment, we will see records like below: environment, we will see records like below:
sample.org. IN MX 1 mx1.sample.org. sample.org. IN MX 1 mx1.sample.org.
IN MX 10 mx10.sample.org. IN MX 10 mx10.sample.org.
mx1.sample.org. IN A 1.0.0.1 ; IPv4/v6 dual stack mx1.sample.org. IN A 1.0.0.1 ; IPv4/v6 dual stack
IN AAAA 3ffe:501:ffff::1 IN AAAA 3ffe:501:ffff::1
skipping to change at page 3, line 44 skipping to change at page 3, line 44
(2) We have multiple MX records with us. Loop steps from (3) to (8), (2) We have multiple MX records with us. Loop steps from (3) to (8),
based on MX preference values, in ascending order. based on MX preference values, in ascending order.
(3) If the source MTA has IPv4 capability, lookup A record. Keep the (3) If the source MTA has IPv4 capability, lookup A record. Keep the
resulting address till step (5). resulting address till step (5).
(4) If the source MTA has IPv6 capability, lookup AAAA record. (4) If the source MTA has IPv6 capability, lookup AAAA record.
(5) Reorder queried result based on implementation-dependent preference (5) Reorder queried result based on implementation-dependent preference
between A and AAAA records. between A and AAAA records. If you would like to encourage the
transition from IPv4 SMTP to IPv6 SMTP, AAAAs should take
precedence.
(6) Loop steps from (7) to (8), for all the addresses (or part of the (6) Loop steps from (7) to (8), for all the addresses (or part of the
list of addresses) we have. If no reachable destination is found, list of addresses) we have. If no reachable destination is found,
and if we are going through a list of MX records, go back to (3) and if we are going through a list of MX records, go back to (3)
and try the next MX record. If we do not have a list of MX and try the next MX record. If we do not have a list of MX
records, or we have reached the end of the list of MX records, records, or we have reached the end of the list of MX records,
raise temporary delivery failure (finish). raise temporary delivery failure (finish).
(7) Try to make a TCP connection to the destination. If it fails, try (7) Try to make a TCP connection to the destination. If it fails, try
the next address we have. If it succeeds, go to step (8). the next address we have. If it succeeds, go to step (8).
DRAFT IPv6 SMTP operational requirements July 2001
(8) Try a SMTP protocol negotiation. If SMTP protocol negotiation (8) Try a SMTP protocol negotiation. If SMTP protocol negotiation
fails with TEMPFAIL (4xx), go back to (3) and try the next MX fails with TEMPFAIL (4xx), go back to (3) and try the next MX
record. If it succeeds, SMTP delivery was successful (finish). record. If it succeeds, SMTP delivery was successful (finish).
DRAFT IPv6 SMTP operational requirements April 2001
4. MX configuration in receipient domain 4. MX configuration in receipient domain
4.1. Ensuring reachability for both protocol versions 4.1. Ensuring reachability for both protocol versions
If a site has IPv4/v6 dual stack reachability, the site SHOULD configure If a site has IPv4/v6 dual stack reachability, the site SHOULD configure
both A and AAAA records onto its MX hosts. It will help both IPv4 and both A and AAAA records onto its MX hosts. It will help both IPv4 and
IPv6 senders to reach the site efficienlty. IPv6 senders to reach the site efficienlty.
4.2. Reachability between primary and secondary MX 4.2. Reachability between primary and secondary MX
skipping to change at page 4, line 53 skipping to change at page 5, line 5
sample.org. IN MX 1 mx1.sample.org. ; IPv4/v6 dual stack sample.org. IN MX 1 mx1.sample.org. ; IPv4/v6 dual stack
IN MX 10 mx10.sample.org. ; IPv4 only IN MX 10 mx10.sample.org. ; IPv4 only
IN MX 100 mx100.sample.org. ; IPv6 only IN MX 100 mx100.sample.org. ; IPv6 only
There are many other ways to ensure the reachability between secondary There are many other ways to ensure the reachability between secondary
MX and primary MX. For example, we could configure secondary MX to MX and primary MX. For example, we could configure secondary MX to
route emails statically, without considering DNS MX configuration. Or route emails statically, without considering DNS MX configuration. Or
we could estalish alternative email routing path (i.e. UUCP, or via we could estalish alternative email routing path (i.e. UUCP, or via
IPv4/v6 translator) between secondary MX and the primary MX. IPv4/v6 translator) between secondary MX and the primary MX.
DRAFT IPv6 SMTP operational requirements July 2001
5. Open issues 5. Open issues
o How to interpret scoped address on MTAs. As we relay emails between o How to interpret scoped address on MTAs. As we relay emails between
MTAs, interpretation of scoped address can be different between MTAs, MTAs, interpretation of scoped address can be different between MTAs,
as intermediate MTAs may be in different scope zone as the originator. as intermediate MTAs may be in different scope zone as the originator.
DRAFT IPv6 SMTP operational requirements April 2001
If we get scoped IPv6 address as a result of DNS lookups, how MTAs If we get scoped IPv6 address as a result of DNS lookups, how MTAs
should behave? If we consider scoped address in ``route-addr'' should behave? If we consider scoped address in ``route-addr''
specification [Crocker, 1982] like specification [Crocker, 1982] like
<itojun@kame.net@[fec0::1]@itojun.org> <@kame.net,@[fec0::1]:itojun@itojun.org>
it gets more trickier. it gets more trickier.
6. Security consideration 6. Security consideration
As presented in ``Open issues'' section, it could be problematical if As presented in ``Open issues'' section, it could be problematical if
route-addr email address format is used across multiple scope zones. route-addr email address format is used across multiple scope zones.
MTAs would need to reject emails with improper route-addr email address MTAs would need to reject emails with improper route-addr email address
formats. formats. A possible example of improper route-addr format would be like
this: an email from outside of the site border, which carries numeric
site-local address in route-addr format.
References References
Partridge, 1986. Partridge, 1986.
C. Partridge, "Mail routing and the domain system" in RFC974 (January C. Partridge, "Mail routing and the domain system" in RFC974 (January
1986). ftp://ftp.isi.edu/in-notes/rfc974.txt. 1986). ftp://ftp.isi.edu/in-notes/rfc974.txt.
Thomson, 1995. Thomson, 1995.
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.
skipping to change at page 5, line 47 skipping to change at page 5, line 54
StJohns, 1993. StJohns, 1993.
M. StJohns, "Identification Protocol" in RFC1413 (January 1993). M. StJohns, "Identification Protocol" in RFC1413 (January 1993).
ftp://ftp.isi.edu/in-notes/rfc1413.txt. ftp://ftp.isi.edu/in-notes/rfc1413.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.
Change history Change history
None. 00 -> 01
Correct email address notation for source-routed emails, based on a
DRAFT IPv6 SMTP operational requirements July 2001
comment from Gregory Neil Shapiro.
Acknowledgements Acknowledgements
The draft was written based on discussions with Japanese IPv6 users, and The draft was written based on discussions with Japanese IPv6 users, and
help from WIDE research group. help from WIDE research group.
DRAFT IPv6 SMTP operational requirements April 2001
Author's address Author's address
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
 End of changes. 

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