7Network Working Group M. Nakamura
8Request for Comments: 3974 Kyoto University
9Category: Informational J. Hagino
10 IIJ Research Laboratory
14 SMTP Operational Experience in Mixed IPv4/v6 Environments
18 This memo provides information for the Internet community. It does
19 not specify an Internet standard of any kind. Distribution of this
24 Copyright (C) The Internet Society (2005).
28 The content of this RFC was at one time considered by the IETF, and
29 therefore it may resemble a current IETF work in progress or a
30 published IETF work. This RFC is not a candidate for any level of
31 Internet Standard. The IETF disclaims any knowledge of the fitness
32 of this RFC for any purpose, and in particular notes that the
33 decision to publish is not based on IETF review for such things as
34 security, congestion control, or inappropriate interaction with
35 deployed protocols. The RFC Editor has chosen to publish this
36 document at its discretion. Readers of this RFC should exercise
37 caution in evaluating its value for implementation and deployment.
39 This document contains a specific interpretation of the applicability
40 of the MX processing algorithm in RFC 2821, Section 5, to dual-stack
41 environments. Implementors are cautioned that they must reference
42 RFC 2821 for the full algorithm; this document is not to be
43 considered a full restatement of RFC 2821, and, in case of ambiguity,
44 RFC 2821 is authoritative.
48 This document discusses SMTP operational experiences in IPv4/v6 dual
49 stack environments. As IPv6-capable SMTP servers are deployed, it
50 has become apparent that certain configurations of MX records are
51 necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This
52 document clarifies the existing problems in the transition period
53 between IPv4 SMTP and IPv6 SMTP. It also defines operational
54 requirements for stable IPv4/v6 SMTP operation.
58Nakamura & Hagino Informational [Page 1]
60RFC 3974 SMTP in Dual Stack Environments January 2005
63 This document does not define any new protocol.
67 Delivery of mail messages to the final mail drop is not always done
68 by direct IP communication between the submitter and final receiver,
69 and there may be some intermediate hosts that relay the messages. So
70 it is difficult to know at message submission (also at receiver side)
71 that all intermediate relay hosts are properly configured. It is not
72 easy to configure all systems consistently since the DNS
73 configuration used by mail message delivery systems is more complex
74 than other Internet services. During the transition period from IPv4
75 to IPv6, more care should be applied to IPv4/v6 interoperability.
77 This document talks about SMTP operational experiences in IPv4/v6
78 dual stack environments. As IPv6-capable SMTP servers are deployed,
79 it has become apparent that certain configurations of MX records are
80 necessary for stable dual-stack (IPv4 and IPv6) SMTP operation.
82 This document does not discuss the problems encountered when the
83 sending MTA and the receiving MTA have no common protocol (e.g., the
84 sending MTA is IPv4-only while the receiving MTA is IPv6-only). Such
85 a situation can be resolved by making either side dual-stack or by
86 making either side use a protocol translator (see Appendix A on
87 issues with protocol translator).
892. Basic DNS Resource Record Definitions for Mail Routing
91 Mail messages on the Internet are typically delivered based on the
92 Domain Name System [Mockapetris]. MX RRs are looked up in DNS to
93 retrieve the names of hosts running MTAs associated with the domain
94 part of the mail address. DNS lookup uses IN class for both IPv4 and
95 IPv6, and similarly IN MX records will be used for mail routing for
96 both IPv4 and IPv6. Hosts which have IPv6 connectivity and also want
97 to have the mails delivered using IPv6 must define IPv6 addresses for
98 the host name as well as IPv4 addresses [Thomson].
100 An MX RR has two parameters, a preference value and the name of
101 destination host. The name of the destination host will be used to
102 look up an IP address to initiate an SMTP connection [Partridge].
114Nakamura & Hagino Informational [Page 2]
116RFC 3974 SMTP in Dual Stack Environments January 2005
119 For example, an IPv6-only site may have the following DNS
122 example.org. IN MX 1 mx1.example.org.
123 IN MX 10 mx10.example.org.
124 mx1.example.org. IN AAAA 2001:db8:ffff::1
125 mx10.example.org. IN AAAA 2001:db8:ffff::2
127 In the transition period from IPv4 to IPv6, there are many IPv4-only
128 sites, and such sites will not have mail interoperability with IPv6-
129 only sites. For the transition period, all mail domains should have
130 MX records such that MX targets with IPv4 and IPv6 addresses exist,
133 example.org. IN MX 1 mx1.example.org.
134 IN MX 10 mx10.example.org.
135 mx1.example.org. IN AAAA 2001:db8:ffff::1
137 mx10.example.org. IN AAAA 2001:db8:ffff::2
140 But, not every MX target may support dual-stack operation. Some host
141 entries may have only A RRs or AAAA RRs:
143 example.org. IN MX 1 mx1.example.org.
144 IN MX 10 mx10.example.org.
145 mx1.example.org. IN AAAA 2001:db8:ffff::1
146 mx10.example.org. IN A 192.0.2.1
148 The following sections discuss how the sender side should operate
149 with IPv4/v6 combined RRs (section 3), and how the receiver should
150 define RRs to maintain interoperability between IPv4 and IPv6
151 networks (section 4).
1533. SMTP Sender Algorithm in a Dual-Stack Environment
155 In a dual-stack environment, MX records for a domain resemble the
158 example.org. IN MX 1 mx1.example.org.
159 IN MX 10 mx10.example.org.
160 mx1.example.org. IN A 192.0.2.1 ; dual-stack
161 IN AAAA 2001:db8:ffff::1
162 mx10.example.org. IN AAAA 2001:db8:ffff::2 ; IPv6-only
164 For a single MX record, there are multiple possible final states,
165 including: (a) one or more A records for the IPv4 destination, (b)
166 one or more AAAA records for the IPv6 destination, (c) a mixture of A
170Nakamura & Hagino Informational [Page 3]
172RFC 3974 SMTP in Dual Stack Environments January 2005
175 and AAAA records. Because multiple MX records may be defined using
176 different preference values, multiple addresses must be traversed
177 based on multiple MXs. Domains without MX records and failure
178 recovery cases must be handled properly as well.
180 The algorithm for a dual-stack SMTP sender is basically the same as
181 that for an IPv4-only sender, but it now includes AAAA lookups of MX
182 records for SMTP-over-IPv6 delivery. IPv4/v6 dual stack destinations
183 should be treated just like multihomed destinations, as described in
184 RFC 2821 [Klensin], section 5. When there is no destination address
185 record found (i.e., the sender MTA is IPv4-only and there are no A
186 records available), the case should be treated just like MX records
187 without address records, and deliveries should fail.
189 ; if the sender MTA is IPv4-only, email delivery to a.example.org
190 ; should fail with the same error as deliveries to b.example.org.
191 a.example.org. IN MX 1 mx1.a.example.org.
192 mx1.a.example.org. IN AAAA 2001:db8:ffff::1 ; IPv6-only
193 b.example.org. IN MX 1 mx1.b.example.org. ; no address
195 An algorithm for a dual-stack SMTP sender is as follows:
198 record is returned, go to the top of step (1) with replacing the
199 destination domain by the query's result. If any MX records are
200 returned, go to step (2) with the query's result (explicit MX).
201 If NODATA (i.e., empty answer with NOERROR(0) RCODE) is
202 returned, there is no MX record but the name is valid. Assume
203 that there is a record like "name. IN MX 0 name." (implicit MX)
204 and go to step (3). If HOST_NOT_FOUND (i.e., empty answer with
205 NXDOMAIN(3) RCODE) is returned, there is no such domain. Raise
206 a permanent email delivery failure. Finish. If SERVFAIL is
207 returned, retry after a certain period of time.
209 (2) Compare each host name in MX records with the names of the
210 sending host. If there is match, drop MX records which have an
211 equal or larger value than the lowest-preference matching MX
212 record (including itself). If multiple MX records remain, sort
213 the MX records in ascending order based on their preference
214 values. Loop over steps (3) to (9) on each host name in MX
215 records in a sequence. If no MX records remain, the sending
216 host must be the primary MX host. Other routing rules should be
219 (3) If the sending MTA has IPv4 capability, lookup the A records.
220 Keep the resulting addresses until step (5).
226Nakamura & Hagino Informational [Page 4]
228RFC 3974 SMTP in Dual Stack Environments January 2005
231 (4) If the sending MTA has IPv6 capability, lookup the AAAA records.
233 NOTE: IPv6 addresses for hosts defined by MX records may be
234 informed in an additional information section of the DNS
235 queries' result as well as IPv4 addresses. If there is no
236 additional address information for the MX hosts, separate
237 queries for A or AAAA records should be sent. There is no way
238 to query A and AAAA records at once in current DNS
241 (5) If there is no A and no AAAA record present, try the next MX
242 record (go to step (3)). Note that the next MX record could
243 have the same preference.
245 NOTE: If one or more address records are found, an
246 implementation may sort addresses based on the implementation's
247 preference of A or AAAA records. To encourage the transition
248 from IPv4 SMTP to IPv6 SMTP, AAAA records should take
249 precedence. The sorting may only reorder addresses from MX
250 records of the same preference. RFC 2821 section 5 paragraph 4
251 suggests randomization of destination addresses. Randomization
252 should only happen among A records, and among AAAA records (do
253 not mix A and AAAA records).
255 (6) For each of the addresses, loop over steps (7) to (9).
257 (7) Try to make a TCP connection to the destination's SMTP port
258 (25). The client needs to follow timeouts documented in RFC
259 2821 section 4.5.3.2. If successful, go to step (9).
261 (8) If unsuccessful and there is another available address, try the
262 next available address. Go to step (7). If all addresses are
263 not reachable and if a list of MX records is being traversed,
264 try the next MX record (go to step (3)). If there is no list of
265 MX records, or if the end of the list of MX records has been
266 reached, raise a temporary email delivery failure. Finish.
269 specified in RFC 2821. If a transient failure condition is
270 reported, try the next MX record (go to step (3)). If an error
271 condition is reported, raise a permanent email delivery error,
272 and do not try further MX records. Finish. If successful, SMTP
273 delivery has succeeded. Finish.
282Nakamura & Hagino Informational [Page 5]
284RFC 3974 SMTP in Dual Stack Environments January 2005
2874. MX Configuration in the Recipient Domain
2894.1. Ensuring Reachability for Both Protocol Versions
291 If a site has dual-stack reachability, the site should configure both
292 A and AAAA records for its MX hosts (NOTE: MX hosts can be outside of
293 the site). This will help both IPv4 and IPv6 senders in reaching the
2964.2. Reachability Between the Primary and Secondary MX
298 When registering MX records in a DNS database in a dual-stack
299 environment, reachability between MX hosts must be considered
300 carefully. Suppose all inbound email is to be gathered at the
301 primary MX host, "mx1.example.org.":
303 example.org. IN MX 1 mx1.example.org.
304 IN MX 10 mx10.example.org.
305 IN MX 100 mx100.example.org.
307 If "mx1.example.org" is an IPv6-only node, and the others are IPv4-
308 only nodes, there is no reachability between the primary MX host and
309 the other MX hosts. When email reaches one of the lower MX hosts, it
310 cannot be relayed to the primary MX host based on MX preferencing
311 mechanism. Therefore, mx1.example.org will not be able to collect
312 all the emails (unless there is another transport mechanism(s)
313 between lower-preference MX hosts and mx1.example.org).
315 ; This configuration is troublesome.
316 ; No secondary MX can reach mx1.example.org.
317 example.org. IN MX 1 mx1.example.org. ; IPv6-only
318 IN MX 10 mx10.example.org. ; IPv4-only
319 IN MX 100 mx100.example.org. ; IPv4-only
321 The easiest possible configuration is to configure the primary MX
322 host as a dual-stack node. By doing so, secondary MX hosts will have
323 no problem reaching the primary MX host.
325 ; This configuration works well.
326 ; The secondary MX hosts are able to relay email to the primary MX
327 ; host without any problems.
328 example.org. IN MX 1 mx1.example.org. ; dual-stack
329 IN MX 10 mx10.example.org. ; IPv4-only
330 IN MX 100 mx100.example.org. ; IPv6-only
332 It may not be necessary for the primary MX host and lower MX hosts to
333 directly reach one another with IPv4 or IPv6 transport. For example,
334 it is possible to establish a routing path with UUCP or an IPv4/v6
338Nakamura & Hagino Informational [Page 6]
340RFC 3974 SMTP in Dual Stack Environments January 2005
343 translator. It is also possible to drop messages into a single
344 mailbox with shared storage using NFS or something else offered by a
345 dual-stack server. It is the receiver site's responsibility that all
346 messages delivered to MX hosts arrive at the recipient's mail drop.
347 In such cases, a dual-stack MX host may not be listed in the MX list.
3495. Operational Experience
351 Many of the existing IPv6-ready MTA's appear to work in the way
352 documented in section 3.
354 There were, however, cases where IPv6-ready MTA's were confused by
355 broken DNS servers. When attempting to obtain a canonical hostname,
356 some broken name servers return SERVFAIL (RCODE 2), a temporary
357 failure on AAAA record lookups. Upon this temporary failure, the
358 email is queued for a later attempt. In the interest of IPv4/v6
359 interoperability, these broken DNS servers should be fixed. A
360 document by Yasuhiro Morishita [Morishita] has more detail on
361 misconfigured/misbehaving DNS servers and their negative side
366 o How should scoped addresses (i.e., link-local addresses) in email
367 addresses be interpreted on MTA's? We suggest prohibiting the use
368 of IPv6 address literals in destination specification.
370 o A future specification of SMTP (revision of RFC 2821) should be
371 updated to include IPv6 concerns presented in this memo, such as
372 (1) the additional query of AAAA RRs where A RRs and/or MX RRs are
373 suggested, and (2) the ordering between IPv6 destination and IPv4
3767. Security Considerations
378 It could be problematic if the route-addr email address format
379 [Crocker] (or "obs-route" address format in [Resnick]) is used across
380 multiple scope zones. MTAs would need to reject email with route-
381 addr email address formats that cross scope zone borders.
394Nakamura & Hagino Informational [Page 7]
396RFC 3974 SMTP in Dual Stack Environments January 2005
399Appendix A. Considerations on Translators
401 IPv6-only MTA to IPv4-only MTA cases could use help from IPv6-to-IPv4
402 translators such as [Hagino]. Normally there are no special SMTP
403 considerations for translators needed. If there is SMTP traffic from
404 an IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4
405 MTA will consider this normal IPv4 SMTP traffic.
407 Protocols like IDENT [St.Johns] may require special consideration
408 when translators are used. Also, there are MTAs which perform strict
409 checks on the SMTP HELO/EHLO "domain" parameter (perform
410 reverse/forward DNS lookups and see if the "domain" really associates
411 to the SMTP client's IP address). In such a case, we need a special
412 consideration when translators will be used (for instance, override
413 "domain" parameter by translator's FQDN/address).
415 Even without a translator, it seems that there are some MTA
416 implementations in the wild which send IPv6 address literals in a
417 HELO/EHLO message (like "HELO [IPv6:blah]"), even when it is using
418 IPv4 transport, or vice versa. If the SMTP peer is IPv4-only, it
419 won't understand the "[IPv6:blah]" syntax and mails won't go out of
420 the (broken) MTA. These implementations have to be corrected.
424 [Mockapetris] Mockapetris, P., "Domain names - implementation and
425 specification", STD 13, RFC 1035, November 1987.
427 [Thomson] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
428 "DNS Extensions to Support IP Version 6", RFC 3596,
431 [Partridge] Partridge, C., "Mail routing and the domain system",
432 STD 10, RFC 974, January 1986.
434 [Klensin] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
437 [Crocker] Crocker, D., "Standard for the format of ARPA Internet
438 text messages", STD 11, RFC 822, August 1982.
440 [Resnick] Resnick, P., "Internet Message Format", RFC 2822, April
443 [Hagino] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at
444 Site Exit Routers", RFC 3178, October 2001.
450Nakamura & Hagino Informational [Page 8]
452RFC 3974 SMTP in Dual Stack Environments January 2005
455 [St.Johns] Johns, M. St., "Identification Protocol", RFC 1413,
458Informative References
460 [Morishita] Morishita, Y. and T. Jinmei, "Common Misbehavior
461 against DNS Queries for IPv6 Addresses", Work in
466 This document was written based on discussions with Japanese IPv6
467 users and help from the WIDE research group. Here is a (probably
468 incomplete) list of people who contributed to the document: Gregory
469 Neil Shapiro, Arnt Gulbrandsen, Mohsen Souissi, JJ Behrens, John C
470 Klensin, Michael A. Patton, Robert Elz, Dean Strik, Pekka Savola, and
476 Academic Center for Computing and Media Studies, Kyoto University
477 Yoshida-honmachi, Sakyo, Kyoto 606-8501, JAPAN
480 EMail: motonori@media.kyoto-u.ac.jp
483 Jun-ichiro itojun HAGINO
484 Research Laboratory, Internet Initiative Japan Inc.
485 1-105, Kanda Jinbo-cho,
486 Chiyoda-ku,Tokyo 101-0051, JAPAN
488 Phone: +81-3-5205-6464
490 EMail: itojun@iijlab.net
506Nakamura & Hagino Informational [Page 9]
508RFC 3974 SMTP in Dual Stack Environments January 2005
511Full Copyright Statement
513 Copyright (C) The Internet Society (2005).
515 This document is subject to the rights, licenses and restrictions
516 contained in BCP 78, and at www.rfc-editor.org, and except as set
517 forth therein, the authors retain all their rights.
519 This document and the information contained herein are provided on an
520 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
521 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
522 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
523 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
524 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
525 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
529 The IETF takes no position regarding the validity or scope of any
530 Intellectual Property Rights or other rights that might be claimed to
531 pertain to the implementation or use of the technology described in
532 this document or the extent to which any license under such rights
533 might or might not be available; nor does it represent that it has
534 made any independent effort to identify any such rights. Information
535 on the ISOC's procedures with respect to rights in ISOC Documents can
536 be found in BCP 78 and BCP 79.
538 Copies of IPR disclosures made to the IETF Secretariat and any
539 assurances of licenses to be made available, or the result of an
540 attempt made to obtain a general license or permission for the use of
541 such proprietary rights by implementers or users of this
542 specification can be obtained from the IETF on-line IPR repository at
543 http://www.ietf.org/ipr.
545 The IETF invites any interested party to bring to its attention any
546 copyrights, patents or patent applications, or other proprietary
547 rights that may cover technology that may be required to implement
548 this standard. Please address the information to the IETF at ietf-
553 Funding for the RFC Editor function is currently provided by the
562Nakamura & Hagino Informational [Page 10]