idnits 2.17.1 draft-motonori-dualstack-smtp-requirement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 8) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 10, 2004) is 7283 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Mokapetris' on line 73 looks like a reference -- Missing reference section? '1987' on line 73 looks like a reference -- Missing reference section? 'Partridge' on line 84 looks like a reference -- Missing reference section? '1986' on line 84 looks like a reference -- Missing reference section? 'Klensin' on line 221 looks like a reference -- Missing reference section? '2001' on line 320 looks like a reference -- Missing reference section? 'Morishita' on line 294 looks like a reference -- Missing reference section? '2003' on line 294 looks like a reference -- Missing reference section? 'Resnick' on line 313 looks like a reference -- Missing reference section? 'Hagino' on line 320 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Motonori Nakamura 2 INTERNET-DRAFT Kyoto University 3 Expires: Novermber 10, 2004 Jun-ichiro itojun Hagino 4 IIJ Research Laboratory 5 May 10, 2004 7 SMTP Operational Experience in Mixed IPv4/v6 Environments 8 draft-motonori-dualstack-smtp-requirement-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as ``work in progress.'' 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 Distribution of this memo is unlimited. 29 The internet-draft will expire in 6 months. The date of expiration will 30 be Novermber 10, 2004. 32 Abstract 34 This document talks about SMTP operational experiences in IPv4/v6 dual 35 stack environments. As IPv6-capable SMTP servers are deployed, it has 36 become apparent that certain configurations of MX records are necessary 37 for stable dual-stack (IPv4 and IPv6) SMTP operation. This document 38 clarifies the problems that exist in the transition period between IPv4 39 SMTP and IPv6 SMTP. It also defines operational requirements for stable 40 IPv4/v6 SMTP operation. 42 This document does not define any new protocol. 44 DRAFT SMTP in Dual Stack Environments May 2004 46 1. Introduction 48 Delivery of mail messages to the final mail drop is not always done by 49 direct IP communication with submitter and final receiver, and there may 50 be some intermediate hosts that relay the messages. So it is difficult 51 to know at message submission (also at receiver side) that all 52 intermediate relay hosts are properly configured. It is not so easy to 53 configure all systems consistently since the DNS configuration used by 54 mail message delivery systems is more complex than other Internet 55 services. During the transition period from IPv4 to IPv6, more care 56 should be applied to IPv4/v6 interoperability. 58 This document talks about SMTP operational experiences in IPv4/v6 dual 59 stack environments. As IPv6-capable SMTP servers are deployed, it has 60 become apparent that certain configurations of MX records are necessary 61 for stable dual-stack (IPv4 and IPv6) SMTP operation. 63 This document does not discuss the problems encountered when the sending 64 MTA and the receiving MTA have no common protocol (e.g. the sending MTA 65 is IPv4-only while the receiving MTA is IPv6-only). Such a situation 66 can be resolved by making either side dual-stack or by making either 67 side use a protocol translator (see Appendix A on issues with protocol 68 translator). 70 2. Basic DNS Resource Record Definitions for Mail Routing 72 Mail messages on the Internet are typically delivered based on Domain 73 Name System [Mokapetris, 1987] . MX RRs are looked up in DNS to 74 retrieve the names of hosts running MTAs associated with the domain part 75 of the mail address. DNS lookup uses IN class for both IPv4 and IPv6, 76 and similarly IN MX records will be used for both IPv4 and IPv6 for mail 77 routing for for both IPv4 and IPv6. Hosts which have IPv6 connectivity 78 and want to have the mails delivered also using the IPv6 must define 79 IPv6 addresses for the host name as well as IPv4 IP addresses [Thomson, 80 2003] . 82 An MX RR have two parameters, a preference value and the name of 83 destination host. The name of destination host will be used to look up 84 an IP address to initiate SMTP connection [Partridge, 1986] . 86 For example, an IPv6-only site may have the following DNS definitions: 88 example.org. IN MX 1 mx1.example.org. 89 IN MX 10 mx10.example.org. 90 mx1.example.org. IN AAAA 2001:db8:ffff::1 91 mx10.example.org. IN AAAA 2001:db8:ffff::2 93 In the transition period from IPv4 to IPv6, there are many IPv4-only 94 sites, and such sites will not have mail interoperability with IPv6-only 95 sites. For the transition period, all mail domains should have MX 96 records such that MX targets with IPv4 and IPv6 addresses exist, e.g. 98 DRAFT SMTP in Dual Stack Environments May 2004 100 example.org. IN MX 1 mx1.example.org. 101 IN MX 10 mx10.example.org. 102 mx1.example.org. IN AAAA 2001:db8:ffff::1 103 IN A 192.0.2.1 104 mx10.example.org. IN AAAA 2001:db8:ffff::2 105 IN A 192.0.2.2 107 But, not every MX target may support dual-stack operation. Some host 108 entries may have only A RRs or AAAA RRs: 110 example.org. IN MX 1 mx1.example.org. 111 IN MX 10 mx10.example.org. 112 mx1.example.org. IN AAAA 2001:db8:ffff::1 113 mx10.example.org. IN A 192.0.2.1 115 The following sections discuss how the sender side should operate with 116 IPv4/v6 combined RRs (section 3) and how the receiver should define RRs 117 to maintain interoperability between IPv4 and IPv6 networks (section 4). 119 3. SMTP Sender Algorithm in a Dual-Stack Environment 121 In a dual-stack environment MX records for a domain resemble the 122 following: 124 example.org. IN MX 1 mx1.example.org. 125 IN MX 10 mx10.example.org. 126 mx1.example.org. IN A 192.0.2.1 ; dual-stack 127 IN AAAA 2001:db8:ffff::1 128 mx10.example.org. IN AAAA 2001:db8:ffff::2 ; IPv6-only 130 For a single MX record there are multiple possible final states, 131 including: (a) one or more A records for the IPv4 destination, (b) one 132 or more AAAA records for the IPv6 destination, (c) a mixture of A and 133 AAAA records. Because multiple MX records may be defined using 134 different preference values, multiple addresses based on multiple MX's 135 must be traversed. Domains without MX records and failure recovery 136 cases must be handled properly as well. 138 The algorithm for a dual-stack SMTP sender is basically the same as that 139 for an IPv4-only sender, but it now includes AAAA lookups of MX records 140 for SMTP-over-IPv6 delivery. IPv4/v6 dual stack destinations should be 141 treated just like multihomed destinations as described in RFC2821 142 [Klensin, 2001] section 5. When there is no usable destination address 143 record found (for example, the sender MTA is IPv4-only and there are no 144 A records available) the case should be treated just like MX records 145 without address records, and deliveries should fail just like such 146 cases. 148 DRAFT SMTP in Dual Stack Environments May 2004 150 ; if the sender MTA is IPv4-only, email delivery to a.example.org 151 ; should fail with the same error as deliveries to b.example.org. 152 a.example.org. IN MX 1 mx1.a.example.org. 153 mx1.a.example.org. IN AAAA 2001:db8:ffff::1 ; IPv6-only 154 b.example.org. IN MX 1 mx1.b.example.org. ; no address 156 An algorithm for a dual-stack SMTP sender is as follows: 158 (1) Lookup the MX record for the destination domain. If a CNAME record 159 is returned, go to the top of step (1) with replacing the 160 destination domain by the query's result. If any MX records are 161 returned, go to step (2) with the query's result (explicit MX). If 162 NODATA (i.e. empty answer with NOERROR(0) RCODE) is returned, 163 there is no MX record but the name is valid. Assume that there is 164 a record like "name. IN MX 0 name." (implicit MX) and go to step 165 (3). If HOST_NOT_FOUND (i.e. empty answer with NXDOMAIN(3) RCODE) 166 is returned, there is no such domain. Raise a permanent email 167 delivery failure. Finish. If SERVFAIL is returned, retry after 168 certain period of time. 170 (2) Compare each host name in MX records with the names of sending 171 host. If there is any match, drop MX records which have equal to 172 or larger than the value of the lowest-preference matching MX 173 record (including itself). If multiple MX records remain, sort the 174 MX records in ascending order based on their preference values. 175 Loop over steps (3) to (9) on each host name in MX records in a 176 sequence. If no MX records remain, the sending host must be the 177 primary MX host. Other routing rule should be applied. Finish. 179 (3) If the sending MTA has IPv4 capability, lookup the A records. Keep 180 the resulting addresses until step (5). 182 (4) If the sending MTA has IPv6 capability, lookup the AAAA records. 184 NOTE: IPv6 addresses for hosts defined by MX records may be 185 informed in additional information section of DNS queries' result 186 as well as IPv4 addresses. If there is no additional address 187 information for the MX hosts, separate queries for A or AAAA 188 records should be sent. There is no way to query A and AAAA 189 records at once in current DNS implementation. 191 (5) If there is no A and no AAAA record present, try the next MX record 192 (go to step (3)). Note that the next MX record could have the same 193 preference. 195 NOTE: If one or more address records are found, an implementation 196 may sort addresses based on the implementation's preference of A or 197 AAAA records. To encourage the transition from IPv4 SMTP to IPv6 198 SMTP, AAAA records should take precedence. The sorting may only 199 reorder addresses from MX records of the same preference. RFC2821 200 section 5 paragraph 4 suggests randomization of destination 201 addresses. Randomization should only happen among A records, and 203 DRAFT SMTP in Dual Stack Environments May 2004 205 among AAAA records (do not mix A and AAAA records). 207 (6) For each of the addresses, loop over steps (7) to (9). 209 (7) Try to make a TCP connection to the destination's SMTP port (25). 210 The client needs to follow timeouts documented in RFC2821 section 211 4.5.3.2. If successful, go to step (9). 213 (8) If unsuccessful and there is another available address, try the 214 next available address. Go to step (7). If all addresses are not 215 reachable and if a list of MX records is being traversed, try the 216 next MX record (go to step (3)). If there is no list of MX 217 records, or if the end of the list of MX records has been reached, 218 raise a temporary email delivery failure. Finish. 220 (9) Attempt to deliver the e-mail over the connection established, as 221 specified in RFC2821 [Klensin, 2001] . If a transient failure 222 condition reported, try the next MX record (go to step (3)). If an 223 error condition reported, raise a permanent email delivery error, 224 and further MX records are not tried. Finish. If successful, SMTP 225 delivery has succeeded. Finish. 227 4. MX Configuration in the Recipient Domain 229 4.1. Ensuring Reachability for Both Protocol Versions 231 If a site has dual-stack reachability, the site should configure both A 232 and AAAA records for its MX hosts (NOTE: MX hosts can be outside of the 233 site). This will help both IPv4 and IPv6 senders to reach the site 234 efficiently. 236 4.2. Reachability Between the Primary and Secondary MX 238 When registering MX records in a DNS database in a dual-stack 239 environment, reachability between MX hosts must be considered carefully. 240 Suppose all inbound email is to be gathered at the primary MX host, 241 "mx1.example.org.": 243 example.org. IN MX 1 mx1.example.org. 244 IN MX 10 mx10.example.org. 245 IN MX 100 mx100.example.org. 247 If "mx1.example.org" is an IPv6-only node, and the others are IPv4-only 248 nodes, there is no reachability between the primary MX host and the 249 other MX hosts. When email reaches one of the lower MX hosts, it cannot 250 be relayed to the primary MX host based on MX preferencing mechanism, 251 therefore mx1.example.org will not be able to collect all the emails 252 (unless there is another transport mechanism(s) between lower-preference 253 MX hosts and mx1.example.org). 255 DRAFT SMTP in Dual Stack Environments May 2004 257 ; This configuration is troublesome. 258 ; No secondary MX can reach mx1.example.org. 259 example.org. IN MX 1 mx1.example.org. ; IPv6-only 260 IN MX 10 mx10.example.org. ; IPv4-only 261 IN MX 100 mx100.example.org. ; IPv4-only 263 The easiest possible configuration is to configure the primary MX host 264 as a dual-stack node. By doing so, secondary MX hosts will have no 265 problem reaching the primary MX host. 267 ; This configuration works well. 268 ; The secondary MX hosts are able to relay email to the primary MX host 269 ; without any problems. 270 example.org. IN MX 1 mx1.example.org. ; dual-stack 271 IN MX 10 mx10.example.org. ; IPv4-only 272 IN MX 100 mx100.example.org. ; IPv6-only 274 It may not be needed that the primary MX host and lower MX hosts reach 275 directly one another with IPv4 or IPv6 transport. For example, it is 276 possible to establish a routing path with UUCP or an IPv4/v6 translator. 277 It is also possible to drop messages into single mailbox with shared 278 storage using NFS or something else offered by a dual-stack server. It 279 is receiver site's matter that all messages delivered to each MX hosts 280 must be reached to recipient's mail drop. In such cases, dual-stack MX 281 host may not be listed in the MX list. 283 5. Operational Experience 285 Many of the existing IPv6-ready MTA's appear to work in the way 286 documented in section 3. 288 There were, however, cases where IPv6-ready MTA's were confused by 289 broken DNS servers. When attempting to obtain a canonical hostname, 290 some broken name servers return SERVFAIL (RCODE 2), a temporary failure, 291 on AAAA record lookups. Upon this temporary failure, the email is 292 queued for a later attempt. In the interest of IPv4/v6 293 interoperability, these broken DNS servers should be fixed. A draft by 294 Yasuhiro Morishita [Morishita, 2003] has more detail on 295 misconfigured/misbehaving DNS servers and their bad sideeffects. 297 6. Open Issues 299 o How should scoped addresses (i.e. link-local addresses) in email 300 addresses be interpreted on MTA's? We suggest prohibiting the use of 301 IPv6 address literals in destination specification. 303 o A future specification of SMTP (revision of RFC2821) should be updated 304 to include IPv6 concerns presented in this memo, such as (1) 305 additional query of AAAA RRs where A RRs and/or MX RRs are suggested, 306 and (2) ordering between IPv6 destination and IPv4 destination. 308 DRAFT SMTP in Dual Stack Environments May 2004 310 7. Security Considerations 312 It could be problematic if the route-addr email address format [Crocker, 313 1982] (or "obs-route" address format in [Resnick, 2001] ) is used 314 across multiple scope zones. MTAs would need to reject email with 315 route-addr email address formats which crosses scope zone borders. 317 Appendix A. Considereations on Translators 319 IPv6-only MTA to IPv4-only MTA case could use help from IPv6-to-IPv4 320 translators such as [Hagino, 2001] . Normally there are no special SMTP 321 considerations for translators needed. If there is SMTP traffic from an 322 IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA 323 will consider this as a normal IPv4 SMTP traffic. 325 Protocols like IDENT [St.Johns, 1993] may require special consideration 326 when translators are used. Also, there are MTAs which perform strict 327 check on SMTP HELO/EHLO "domain" parameter (perform reverse/forward DNS 328 lookups and see if the "domain" really associates to the SMTP client's 329 IP address). In such case we need a special consideration when 330 translators are used (for instance, override "domain" parameter by 331 translator's FQDN/address). 333 Even without a translator, it seems that there are some MTA 334 implementations in the wild which send IPv6 address literal in HELO/EHLO 335 message (like "HELO [IPv6:blah]") even when it is using IPv4 trasport, 336 or vice versa. If the SMTP peer is IPv4-only, it won't understand 337 "[IPv6:blah]" syntax and mails won't go out of the (broken) MTA. These 338 implementations have to be corrected. 340 References 342 Mokapetris, 1987. 343 P.V. Mokapetris, "Domain names - implementation and specification" in 344 RFC1035 (November 1987). ftp://ftp.isi.edu/in-notes/rfc1035.txt. 346 Thomson, 2003. 347 S. Thomson, C. Huitema, V. Ksinant, and M. Souissi, "DNS Extensions to 348 support IP version 6" in RFC3596 (October 2003). ftp://ftp.isi.edu/in- 349 notes/rfc3596.txt. 351 Partridge, 1986. 352 C. Partridge, "Mail routing and the domain system" in RFC974 (January 353 1986). ftp://ftp.isi.edu/in-notes/rfc974.txt. 355 Klensin, 2001. 356 J. Klensin, Editor, "Simple Mail Transfer Protocol" in RFC2821 (April 357 2001). ftp://ftp.isi.edu/in-notes/rfc2821.txt. 359 DRAFT SMTP in Dual Stack Environments May 2004 361 Crocker, 1982. 362 D. Crocker, "Standard for the format of ARPA Internet text messages" in 363 RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt. 365 Resnick, 2001. 366 P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001). 367 ftp://ftp.isi.edu/in-notes/rfc2822.txt. 369 Hagino, 2001. 370 Jun-ichiro Hagino and Hal Snyder, "IPv6 multihoming support at site exit 371 routers" in RFC3178 (October 2001). ftp://ftp.isi.edu/in- 372 notes/rfc3178.txt. 374 St.Johns, 1993. 375 M. St.Johns, "Identification Protocol" in RFC1413 (January 1993). 376 ftp://ftp.isi.edu/in-notes/rfc1413.txt. 378 Informative references 380 Morishita, 2003. 381 Y. Morishita and T. Jinmei, "Common Misbehavior against DNS Queries for 382 IPv6 Addresses" in draft-morishita-dnsop-misbehavior-against-aaaa-00.txt 383 (June 2003). work in progress material. 385 Change history 387 [This section should be removed on publication as an RFC] 389 draft-ietf-ngtrans-ipv6-smtp-requirement-00 -> 01 390 Corrected the email address notation for source-routed emails, 391 based on a comment from Gregory Neil Shapiro. 393 01 -> 02 394 Change a reference to refer to RFC2822, not 822. Used 395 "example.org", not "sample.org". These changes were based on 396 comments from Arnt Gulbrandsen. Added an ``Operational 397 experiences'' section. Clarified the case where an MX record 398 points to a CNAME record, based on comments from Mohsen Souissi. 400 02 -> 03 401 In some cases, IPv6-ready MTAs are troubled by incorrect DNS server 402 responses for AAAA queries. This change was based on comments from 403 Gregory Neil Shapiro. 405 03 -> 04 406 Grammar cleanups by JJ Behrens. More text on the delivery error 407 cases. 409 04 -> 05 410 Change title, suggested by Alain Durand. Limit the scope of the 412 DRAFT SMTP in Dual Stack Environments May 2004 414 document to dual stack environment (interoperation of IPv6-only 415 cloud and IPv4-only cloud is out of scope). 417 05 -> 06 418 Section on summary of IPv4 MX operation is deleted (Replaced by 419 Introduction). Clarify on CNAME chain. Cleanups on sender's 420 algorithm. Suggested by Patrik Faltstrom. 422 06 -> 07 423 Site local address is being obsoleted in IPv6 wg, so remove 424 reference to site-locals. Reflect comments from John C Klensin: 425 fixes to sending rules, correct route-addr issues. Reflect 426 comments from Michael A. Patton: HELO on connection via translator. 427 Reflect comments from Robert Elz. 429 07 -> 08 430 Refer a draft by Yasuhiro Morishita. 432 08 -> draft-motonori-dualstack-smtp-requirement-00 433 Back to personal submission as suggested by ADs. Many comments 434 from Dean Strik and Pekka Savola. Split consideration on 435 translators into Appendix A. 437 draft-motonori-dualstack-smtp-requirement-00 -> 01 438 Reflect comments from dean Strik, Pekka Savola and Rob Austein. 439 Split normative and informative references. 441 Acknowledgements 443 This draft was written based on discussions with Japanese IPv6 users and 444 help from the WIDE research group. Here is a (probably incomplete) list 445 of people who contributed to the draft: Gregory Neil Shapiro, Arnt 446 Gulbrandsen, Mohsen Souissi, JJ Behrens, John C Klensin, Michael A. 447 Patton, Robert Elz, Dean Strik, Pekka Savola, and Rob Austein. 449 Authors' address 451 DRAFT SMTP in Dual Stack Environments May 2004 453 Motonori NAKAMURA 454 Academic Center for Computing and Media Studies, Kyoto University 455 Yoshida-honmachi, Sakyo, Kyoto 606-8501, JAPAN 456 Fax: +81-75-753-7450 457 Email: motonori@media.kyoto-u.ac.jp 459 Jun-ichiro itojun HAGINO 460 Research Laboratory, Internet Initiative Japan Inc. 461 1-105, Kanda Jinbo-cho, 462 Chiyoda-ku,Tokyo 101-0051, JAPAN 463 Tel: +81-3-5205-6464 464 Fax: +81-3-5205-6466 465 Email: itojun@iijlab.net