Internet DRAFT - draft-moonesamy-smtp-ipv6
draft-moonesamy-smtp-ipv6
Network Working Group S. Moonesamy
Internet Draft May 22, 2012
Obsoletes: 3974 (if approved)
Intended status: Informational
Expires: November 21, 2012
SMTP in an IPv4/IPv6 dual stack Environment
draft-moonesamy-smtp-ipv6-01.txt
Abstract
This memo discusses about SMTP in an IPv4/IPv6 dual stack
environment. It documents the algorithm initially specified in
RFC 3974 which is used in several SMTP implementations.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on Noevmber 21, 2012
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
S. Moonesamy Expires November 2012 [Page 1]
Internet Draft SMTP and IPv6 May 22, 2012
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before
November 10, 2008. The person(s) controlling the copyright in
some of this material may not have granted the IETF Trust the
right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license
from the person(s) controlling the copyright in such materials,
this document may not be modified outside the IETF Standards
Process, and derivative works of it may not be created outside
the IETF Standards Process, except to format it for publication
as an RFC or to translate it into languages other than English.
S. Moonesamy Expires November 2012 [Page 2]
Internet Draft SMTP and IPv6 May 22, 2012
1. Introduction
This memo discusses about SMTP in an IPv4/IPv6 dual stack
environment. It contains a specific interpretation, initially
specified in RFC 3974, of the applicability of the MX processing
algorithm in RFC 5321, Section 5, to dual-stack environments.
Implementers are cautioned that they must reference RFC 5321 for the
full algorithm; in case of ambiguity, RFC 5321 is authoritative.
This memo obsoletes RFC 3974 [RFC3974].
2. SMTP Sender Algorithm in a Dual-Stack Environment
The algorithm for a dual-stack SMTP sender is basically the same as
that for an IPv4-only SMTP client, but it now includes AAAA lookups
of DNS MX records for SMTP-over-IPv6 relaying. IPv4/IPv6 dual stack
destinations should be treated just like multihomed destinations, as
described in RFC 5321 [RFC5321], Section 5.
Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in RFC 5321 Sections 2.3.5
and 3.6), a DNS lookup must be performed to resolve the domain name
(RFC 1035 [RFC1035]). The names are expected to be fully-qualified
domain names (FQDNs); mechanisms for inferring FQDNs from partial
names or local aliases are outside the scope of this specification.
(1) As specified in RFC 5321, the lookup first attempts to locate an
MX RR associated with the name. If a CNAME record is found, the
resulting name is processed as if it were the initial name. If a
non-existent domain error is returned, this situation must be
reported as an error. If a temporary error is returned, the
message must be queued and retried later (see RFC 5321 Section
4.5.4.1). If an empty list of MXs is returned, the address is
treated as if it was associated with an implicit MX RR, with a
preference of 0, pointing to that host. If MX RRs are present,
but none of them are usable, or the implicit MX RR is unusable,
this situation must be reported as an error.
(2) Compare each host name in MX RR with the names of the sending
host. If there is match, drop MX RRs which have an equal or
larger value than the lowest-preference matching MX RR
(including itself). If multiple MX RRs remain, sort the MX RRs
in ascending order based on their preference values. Loop over
steps (3) to (9) on each host name in MX RR in a sequence. If
no MX RRs remain, the SMTP client must be the primary MX host.
Other routing rules should be applied. Finish.
(3) If the sending MTA has IPv4 capability, lookup the A RR.
S. Moonesamy Expires November 2012 [Page 3]
Internet Draft SMTP and IPv6 May 22, 2012
Keep the resulting addresses until step (5).
(4) If the sending MTA has IPv6 capability, lookup the AAAA RRs.
(5) If there is no A or AAAA RR present, try the next MX RR (go to
step (3)). Note that the next MX RR could have the same
preference.
NOTE: If one or more address RRs are found, an implementation
may sort addresses RRs based on the implementation's preference
of A or AAAA RR. To encourage the transition from IPv4 to
IPv6, AAAA RRs may take precedence. The sorting may only
reorder address RRs from MX RRs of the same preference.
(6) For each of the addresses, loop over steps (7) to (9).
(7) An SMTP session is initiated with the SMTP client opening a
connection to the SMTP server as specified in RFC 5321
Section 3.1. The SMTP client needs to adhere to the timeouts
specified in RFC 5321 Section 4.5.3.2 and the sending strategy
defined in RFC 5321 Section 4.5.4.1.
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 RRs is being traversed,
try the next MX RR (go to step (3)). If there is no list of
MX RRs, or if the end of the list of MX RRs has been
reached, raise a temporary email delivery failure. Finish.
(9) Attempt to deliver the email over the connection established, as
specified in RFC 5321. If a transient failure condition is
reported, try again as defined in RFC 5321 Section 4.5.4.1.
Finish.
3. Security Considerations
Section 7 of RFC 5321 discusses about the security considerations for
SMTP implementations should provide the capability for filtering in
an IPv6 environment similar to what is currently available in an IPv4
environment.
4. IANA Considerations
This document does not require the IANA to take any action.
5. Acknowledgements
S. Moonesamy Expires November 2012 [Page 4]
Internet Draft SMTP and IPv6 May 22, 2012
This document borrows text from RFC 3974 which was written by
Motonori Nakamura and Jun-ichiro itojun Hagino. Here is a list of
people who contributed to RFC 3974: Gregory Neil Shapiro,
Arnt Gulbrandsen, Mohsen Souissi, JJ Behrens, John C Klensin,
Michael A. Patton, Robert Elz, Dean Strik, Pekka Savola,
and Rob Austein.
The author would like to acknowledge the following people for
their review of this document: Frank Ellermann, Murray Kucherawy,
and John Levine.
Some of the text in this document was copied from RFC 5321.
6. References
6.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
6.1. Informative References
[RFC3974] Nakamura, M. and Hagino, J., "SMTP Operational
Experience in Mixed IPv4/v6 Environments", RFC 3974,
January 2005.
Author's Address
S. Moonesamy
76, Ylang Ylang Avenue
Quatre Bornes
Mauritius
Email: sm+ietf@elandsys.com
bp
Appendix A: DNS Resource Records examples
A.1: IPv6-only hosts
The target hosts for example.org are only reachable over IPv6.
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
S. Moonesamy Expires November 2012 [Page 5]
Internet Draft SMTP and IPv6 May 22, 2012
mx1.example.org. IN AAAA 2001:db8:ffff::1
mx2.example.org. IN AAAA 2001:db8:ffff::2
A.2: IPv4/IPv6 dual-stack hosts
The target hosts for example.org are reachable over IPv4 and IPv6 as
they support dual-stack operation.
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
mx2.example.org. IN AAAA 2001:db8:aaaa::1
IN A 198.51.100.1
A.3: IPv4 and IPv6 hosts
mx1.example.org which is a target host for example.org is only reachable
over IPv6 while the mx2.example.com target host is only reachable over IPv4.
The target hosts do not support dual-stack operation. mx2.example.com uses
an unlisted smart host which supports dual-stack operation to deliver mail
to mx1.example.org.
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
mx2.example.com. IN A 203.0.113.0.1
Appendix B: Changes from RFC 3974
This appendix contains a list of changes between this document and
RFC 3974.
- Removal of the Basic DNS Resource Record Definitions for Mail Routing section
- Removal of the SMTP Sender Algorithm in a Dual-Stack Environment section
- Removal of the Operational Experience and open issues sections.
- RFC 5321 remains authoritative for SMTP
Appendix C: Change Log
C.1: Changes between between version -00 and version -01
- Step 9 references RFC 5321 Section 4.5.4.1
- Added DNS Resource Records examples to Appendix A
S. Moonesamy Expires November 2012 [Page 6]
