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]