From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3974.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc3974.txt (limited to 'doc/rfc/rfc3974.txt') diff --git a/doc/rfc/rfc3974.txt b/doc/rfc/rfc3974.txt new file mode 100644 index 0000000..fb86cd5 --- /dev/null +++ b/doc/rfc/rfc3974.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group M. Nakamura +Request for Comments: 3974 Kyoto University +Category: Informational J. Hagino + IIJ Research Laboratory + January 2005 + + + SMTP Operational Experience in Mixed IPv4/v6 Environments + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +IESG Note: + + The content of this RFC was at one time considered by the IETF, and + therefore it may resemble a current IETF work in progress or a + published IETF work. This RFC is not a candidate for any level of + Internet Standard. The IETF disclaims any knowledge of the fitness + of this RFC for any purpose, and in particular notes that the + decision to publish is not based on IETF review for such things as + security, congestion control, or inappropriate interaction with + deployed protocols. The RFC Editor has chosen to publish this + document at its discretion. Readers of this RFC should exercise + caution in evaluating its value for implementation and deployment. + + This document contains a specific interpretation of the applicability + of the MX processing algorithm in RFC 2821, Section 5, to dual-stack + environments. Implementors are cautioned that they must reference + RFC 2821 for the full algorithm; this document is not to be + considered a full restatement of RFC 2821, and, in case of ambiguity, + RFC 2821 is authoritative. + +Abstract + + This document discusses SMTP operational experiences in IPv4/v6 dual + stack environments. As IPv6-capable SMTP servers are deployed, it + has become apparent that certain configurations of MX records are + necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This + document clarifies the existing problems in the transition period + between IPv4 SMTP and IPv6 SMTP. It also defines operational + requirements for stable IPv4/v6 SMTP operation. + + + +Nakamura & Hagino Informational [Page 1] + +RFC 3974 SMTP in Dual Stack Environments January 2005 + + + This document does not define any new protocol. + +1. Introduction + + Delivery of mail messages to the final mail drop is not always done + by direct IP communication between the submitter and final receiver, + and there may be some intermediate hosts that relay the messages. So + it is difficult to know at message submission (also at receiver side) + that all intermediate relay hosts are properly configured. It is not + easy to configure all systems consistently since the DNS + configuration used by mail message delivery systems is more complex + than other Internet services. During the transition period from IPv4 + to IPv6, more care should be applied to IPv4/v6 interoperability. + + This document talks about SMTP operational experiences in IPv4/v6 + dual stack environments. As IPv6-capable SMTP servers are deployed, + it has become apparent that certain configurations of MX records are + necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. + + 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 can be resolved by making either side dual-stack or by + making either side use a protocol translator (see Appendix A on + issues with protocol translator). + +2. Basic DNS Resource Record Definitions for Mail Routing + + Mail messages on the Internet are typically delivered based on the + Domain Name System [Mockapetris]. MX RRs are looked up in DNS to + retrieve the names of hosts running MTAs associated with the domain + part of the mail address. DNS lookup uses IN class for both IPv4 and + IPv6, and similarly IN MX records will be used for mail routing for + both IPv4 and IPv6. Hosts which have IPv6 connectivity and also want + to have the mails delivered using IPv6 must define IPv6 addresses for + the host name as well as IPv4 addresses [Thomson]. + + An MX RR has two parameters, a preference value and the name of + destination host. The name of the destination host will be used to + look up an IP address to initiate an SMTP connection [Partridge]. + + + + + + + + + + + +Nakamura & Hagino Informational [Page 2] + +RFC 3974 SMTP in Dual Stack Environments January 2005 + + + For example, an IPv6-only site may have the following DNS + definitions: + + example.org. IN MX 1 mx1.example.org. + IN MX 10 mx10.example.org. + mx1.example.org. IN AAAA 2001:db8:ffff::1 + mx10.example.org. IN AAAA 2001:db8:ffff::2 + + In the transition period from IPv4 to IPv6, there are many IPv4-only + sites, and such sites will not have mail interoperability with IPv6- + only sites. For the transition period, all mail domains should have + MX records such that MX targets with IPv4 and IPv6 addresses exist, + e.g., + + 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 + mx10.example.org. IN AAAA 2001:db8:ffff::2 + IN A 192.0.2.2 + + But, not every MX target may support dual-stack operation. Some host + entries may have only A RRs or AAAA RRs: + + example.org. IN MX 1 mx1.example.org. + IN MX 10 mx10.example.org. + mx1.example.org. IN AAAA 2001:db8:ffff::1 + mx10.example.org. IN A 192.0.2.1 + + The following sections discuss how the sender side should operate + with IPv4/v6 combined RRs (section 3), and how the receiver should + define RRs to maintain interoperability between IPv4 and IPv6 + networks (section 4). + +3. SMTP Sender Algorithm in a Dual-Stack Environment + + In a dual-stack environment, MX records for a domain resemble the + following: + + example.org. IN MX 1 mx1.example.org. + IN MX 10 mx10.example.org. + mx1.example.org. IN A 192.0.2.1 ; dual-stack + IN AAAA 2001:db8:ffff::1 + mx10.example.org. IN AAAA 2001:db8:ffff::2 ; IPv6-only + + For a single MX record, there are multiple possible final states, + including: (a) one or more A records for the IPv4 destination, (b) + one or more AAAA records for the IPv6 destination, (c) a mixture of A + + + +Nakamura & Hagino Informational [Page 3] + +RFC 3974 SMTP in Dual Stack Environments January 2005 + + + and AAAA records. Because multiple MX records may be defined using + different preference values, multiple addresses must be traversed + based on multiple MXs. Domains without MX records and failure + recovery cases must be handled properly as well. + + The algorithm for a dual-stack SMTP sender 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 + RFC 2821 [Klensin], section 5. When there is no destination address + record found (i.e., the sender MTA is IPv4-only and there are no A + records available), the case should be treated just like MX records + without address records, and deliveries should fail. + + ; 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 2001:db8:ffff::1 ; IPv6-only + b.example.org. IN MX 1 mx1.b.example.org. ; no address + + An algorithm for a dual-stack SMTP sender is as follows: + + (1) Lookup the MX record for the destination domain. If a CNAME + record is returned, go to the top of step (1) with replacing the + destination domain by the query's result. If any MX records are + returned, go to step (2) with the query's result (explicit MX). + If NODATA (i.e., empty answer with NOERROR(0) RCODE) is + returned, there is no MX record but the name is valid. Assume + that there is a record like "name. IN MX 0 name." (implicit MX) + and go to step (3). If HOST_NOT_FOUND (i.e., empty answer with + NXDOMAIN(3) RCODE) is returned, there is no such domain. Raise + a permanent email delivery failure. Finish. If SERVFAIL is + returned, retry after a certain period of time. + + (2) Compare each host name in MX records with the names of the + sending host. If there is match, drop MX records which have an + equal or larger value than the lowest-preference matching MX + record (including itself). If multiple MX records remain, sort + the MX records in ascending order based on their preference + values. Loop over steps (3) to (9) on each host name in MX + records in a sequence. If no MX records remain, the sending + host must be the primary MX host. Other routing rules should be + applied. Finish. + + (3) If the sending MTA has IPv4 capability, lookup the A records. + Keep the resulting addresses until step (5). + + + + + +Nakamura & Hagino Informational [Page 4] + +RFC 3974 SMTP in Dual Stack Environments January 2005 + + + (4) If the sending MTA has IPv6 capability, lookup the AAAA records. + + NOTE: IPv6 addresses for hosts defined by MX records may be + informed in an additional information section of the DNS + queries' result as well as IPv4 addresses. If there is no + additional address information for the MX hosts, separate + queries for A or AAAA records should be sent. There is no way + to query A and AAAA records at once in current DNS + implementation. + + (5) If there is no A and no AAAA record present, try the next MX + record (go to step (3)). Note that the next MX record could + have the same preference. + + NOTE: If one or more address records are found, an + implementation may sort addresses based on the implementation's + preference of A or AAAA records. To encourage the transition + from IPv4 SMTP to IPv6 SMTP, AAAA records should take + precedence. The sorting may only reorder addresses from MX + records of the same preference. RFC 2821 section 5 paragraph 4 + suggests randomization of destination addresses. Randomization + should only happen among A records, and among AAAA records (do + not mix A and AAAA records). + + (6) For each of the addresses, loop over steps (7) to (9). + + (7) Try to make a TCP connection to the destination's SMTP port + (25). The client needs to follow timeouts documented in RFC + 2821 section 4.5.3.2. 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 records is being traversed, + try the next MX record (go to step (3)). If there is no list of + MX records, or if the end of the list of MX records has been + reached, raise a temporary email delivery failure. Finish. + + (9) Attempt to deliver the email over the connection established, as + specified in RFC 2821. If a transient failure condition is + reported, try the next MX record (go to step (3)). If an error + condition is reported, raise a permanent email delivery error, + and do not try further MX records. Finish. If successful, SMTP + delivery has succeeded. Finish. + + + + + + + + +Nakamura & Hagino Informational [Page 5] + +RFC 3974 SMTP in Dual Stack Environments January 2005 + + +4. MX Configuration in the Recipient Domain + +4.1. Ensuring Reachability for Both Protocol Versions + + If a site has dual-stack reachability, the site should configure both + A and AAAA records for its MX hosts (NOTE: MX hosts can be outside of + the site). This will help both IPv4 and IPv6 senders in reaching the + site efficiently. + +4.2. Reachability Between the Primary and Secondary MX + + When registering MX records in a DNS database in a dual-stack + environment, reachability between MX hosts must be considered + carefully. Suppose all inbound email is to be gathered at the + primary MX host, "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" is an IPv6-only node, and the others are IPv4- + only nodes, there is no reachability between the primary MX host and + the other MX hosts. When email reaches one of the lower MX hosts, it + cannot be relayed to the primary MX host based on MX preferencing + mechanism. Therefore, mx1.example.org will not be able to collect + all the emails (unless there is another transport mechanism(s) + between lower-preference MX hosts and mx1.example.org). + + ; This configuration is troublesome. + ; 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 a dual-stack node. By doing so, secondary MX hosts will have + no problem reaching the primary MX host. + + ; This configuration works well. + ; The secondary MX hosts are able to relay email to the primary MX + ; host without any problems. + example.org. IN MX 1 mx1.example.org. ; dual-stack + IN MX 10 mx10.example.org. ; IPv4-only + IN MX 100 mx100.example.org. ; IPv6-only + + It may not be necessary for the primary MX host and lower MX hosts to + directly reach one another with IPv4 or IPv6 transport. For example, + it is possible to establish a routing path with UUCP or an IPv4/v6 + + + +Nakamura & Hagino Informational [Page 6] + +RFC 3974 SMTP in Dual Stack Environments January 2005 + + + translator. It is also possible to drop messages into a single + mailbox with shared storage using NFS or something else offered by a + dual-stack server. It is the receiver site's responsibility that all + messages delivered to MX hosts arrive at the recipient's mail drop. + In such cases, a dual-stack MX host may not be listed in the MX list. + +5. Operational Experience + + Many of the existing IPv6-ready MTA's appear to work in the way + documented in section 3. + + There were, however, cases where IPv6-ready MTA's were confused by + broken DNS servers. When attempting to obtain a canonical hostname, + some broken name servers return SERVFAIL (RCODE 2), a temporary + failure on AAAA record lookups. Upon this temporary failure, the + email is queued for a later attempt. In the interest of IPv4/v6 + interoperability, these broken DNS servers should be fixed. A + document by Yasuhiro Morishita [Morishita] has more detail on + misconfigured/misbehaving DNS servers and their negative side + effects. + +6. Open Issues + + o How should scoped addresses (i.e., link-local addresses) in email + addresses be interpreted on MTA's? We suggest prohibiting the use + of IPv6 address literals in destination specification. + + o A future specification of SMTP (revision of RFC 2821) should be + updated to include IPv6 concerns presented in this memo, such as + (1) the additional query of AAAA RRs where A RRs and/or MX RRs are + suggested, and (2) the ordering between IPv6 destination and IPv4 + destination. + +7. Security Considerations + + It could be problematic if the route-addr email address format + [Crocker] (or "obs-route" address format in [Resnick]) is used across + multiple scope zones. MTAs would need to reject email with route- + addr email address formats that cross scope zone borders. + + + + + + + + + + + + +Nakamura & Hagino Informational [Page 7] + +RFC 3974 SMTP in Dual Stack Environments January 2005 + + +Appendix A. Considerations on Translators + + IPv6-only MTA to IPv4-only MTA cases could use help from IPv6-to-IPv4 + translators such as [Hagino]. Normally there are no special SMTP + considerations for translators needed. 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 IPv4 SMTP traffic. + + Protocols like IDENT [St.Johns] may require special consideration + when translators are used. Also, there are MTAs which perform strict + checks on the SMTP HELO/EHLO "domain" parameter (perform + reverse/forward DNS lookups and see if the "domain" really associates + to the SMTP client's IP address). In such a case, we need a special + consideration when translators will be used (for instance, override + "domain" parameter by translator's FQDN/address). + + Even without a translator, it seems that there are some MTA + implementations in the wild which send IPv6 address literals in a + HELO/EHLO message (like "HELO [IPv6:blah]"), even when it is using + IPv4 transport, or vice versa. If the SMTP peer is IPv4-only, it + won't understand the "[IPv6:blah]" syntax and mails won't go out of + the (broken) MTA. These implementations have to be corrected. + +Normative References + + [Mockapetris] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [Thomson] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [Partridge] Partridge, C., "Mail routing and the domain system", + STD 10, RFC 974, January 1986. + + [Klensin] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [Crocker] Crocker, D., "Standard for the format of ARPA Internet + text messages", STD 11, RFC 822, August 1982. + + [Resnick] Resnick, P., "Internet Message Format", RFC 2822, April + 2001. + + [Hagino] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at + Site Exit Routers", RFC 3178, October 2001. + + + + + +Nakamura & Hagino Informational [Page 8] + +RFC 3974 SMTP in Dual Stack Environments January 2005 + + + [St.Johns] Johns, M. St., "Identification Protocol", RFC 1413, + February 1993. + +Informative References + + [Morishita] Morishita, Y. and T. Jinmei, "Common Misbehavior + against DNS Queries for IPv6 Addresses", Work in + Progress, June 2003. + +Acknowledgements + + This document was written based on discussions with Japanese IPv6 + users and help from the WIDE research group. Here is a (probably + incomplete) list of people who contributed to the document: Gregory + Neil Shapiro, Arnt Gulbrandsen, Mohsen Souissi, JJ Behrens, John C + Klensin, Michael A. Patton, Robert Elz, Dean Strik, Pekka Savola, and + Rob Austein. + +Authors' Addresses + + Motonori NAKAMURA + Academic Center for Computing and Media Studies, Kyoto University + Yoshida-honmachi, Sakyo, Kyoto 606-8501, JAPAN + + Fax: +81-75-753-7450 + EMail: motonori@media.kyoto-u.ac.jp + + + Jun-ichiro itojun HAGINO + Research Laboratory, Internet Initiative Japan Inc. + 1-105, Kanda Jinbo-cho, + Chiyoda-ku,Tokyo 101-0051, JAPAN + + Phone: +81-3-5205-6464 + Fax: +81-3-5205-6466 + EMail: itojun@iijlab.net + + + + + + + + + + + + + + + +Nakamura & Hagino Informational [Page 9] + +RFC 3974 SMTP in Dual Stack Environments January 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and at www.rfc-editor.org, and except as set + forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the ISOC's procedures with respect to rights in ISOC Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Nakamura & Hagino Informational [Page 10] + -- cgit v1.2.3