idnits 2.17.1 draft-ietf-ngtrans-ipv6-smtp-requirement-08.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 8 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 247: '...bility, the site SHOULD configure both...' 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 (January 15, 2004) is 7407 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? 'Hagino' on line 66 looks like a reference -- Missing reference section? '2001' on line 327 looks like a reference -- Missing reference section? 'Thomson' on line 87 looks like a reference -- Missing reference section? '1995' on line 87 looks like a reference -- Missing reference section? 'Partridge' on line 95 looks like a reference -- Missing reference section? '1986' on line 95 looks like a reference -- Missing reference section? 'Klensin' on line 327 looks like a reference -- Missing reference section? 'Morishita' on line 313 looks like a reference -- Missing reference section? '2003' on line 313 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 5 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: July 15, 2004 Jun-ichiro itojun Hagino 4 IIJ Research Laboratory 5 January 15, 2004 7 SMTP operational experience in mixed IPv4/IPv6 environements 8 draft-ietf-ngtrans-ipv6-smtp-requirement-08.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 July 15, 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 are necessary in 37 IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP 38 operation. This document clarifies the problems that exist in the 39 transition period between IPv4 SMTP and IPv6 SMTP. It also defines 40 operational requirements for stable IPv4/v6 SMTP operation. 42 This document does not define any new protocol. 44 ^L 46 DRAFT SMTP in dual stack environments January 2004 48 1. Introduction 50 Deliveries of mail messages to the final mail drop is not always done by 51 direct IP communication with submiter and final receiver, and there may 52 be some intermediate hosts to relay the messages. So it is difficult to 53 know at message submission (also at receiver side) that all intermediate 54 relay hosts are properly configured. It is not so easy to configure all 55 the system with consistency since mail message delivery system is rather 56 complex on DNS setting than other Internet services. For the transition 57 state from IPv4 to IPv6, both IPv4 and IPv6 interoperability should be 58 kept more carefully. 60 There are several technologies defined for the transition from IPv4 to 61 IPv6. This document concentrates on SMTP issues in a dual-stack 62 environment, e.g. delivery of emails from IPv6-only MTA to IPv4-only MTA 63 is outside of the scope of the document. 65 IPv6-only MTA to IPv4-only MTA case could use help from IPv6-to-IPv4 66 translators such as [Hagino, 2001] , however, there are no special SMTP 67 considerations for translators needed; If there is SMTP traffic from an 68 IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA 69 will consider this as a normal IPv4 SMTP traffic. Protocols like IDENT 70 [St.Johns, 1993] as well as SMTP HELO/EHLO may require special 71 consideration when translators are used. 73 The following sections explain how to make IPv4 SMTP and IPv6 SMTP 74 coexist in a dual-stack environment. 76 This document does not discuss the problems encountered when the sending 77 MTA and the receiving MTA have no common protocol (e.g. the sending MTA 78 is IPv4-only while the receiving MTA is IPv6-only). Such a situation 79 should be resolved by making either side dual-stack or by making either 80 side use a protocol translator. 82 2. Basic DNS resource record definitions for mail routing 84 Mail messages on the Internet are delivered based on domain name system 85 generally. MX RRs are looked up to know destination hosts associated 86 with domain part of a mail addresse. Similar to the way RFC's for IPv6 87 DNS lookup [Thomson, 1995] use IN class for both IPv4 and IPv6, IN MX 88 records will be used for both IPv4 and IPv6 on mail message routing, 89 hosts which have IPv6 transport and want to be delivered with the IPv6 90 transport must define IPv6 IP addresses for the host name as well as 91 IPv4 IP addresses. 93 A MX RR have two data, a preference value and the name of destination 94 host. IP addresses for the destination host are also looked up to make 95 SMTP transport [Partridge, 1986] . In IPv4 environment, IPv4 IP 96 addresses are defined with A RRs. 98 ^L 100 DRAFT SMTP in dual stack environments January 2004 102 For example, IPv6 only site may have the following DNS definitions: 104 example.org. IN MX 1 mx1.example.org. 105 IN MX 10 mx10.example.org. 106 mx1.example.org. IN AAAA 3ffe:501:ffff::1 107 mx10.example.org. IN AAAA 3ffe:501:ffff::2 109 In transition period from IPv4 to IPv6, there are many IPv4 sites, and 110 such sites will not have mail interoperability with IPv6 only sites. 111 For the transition period, all mail domains should have MX records such 112 that MX targets with IPv4 and IPv6 addresses exist, e.g, for example: 114 example.org. IN MX 1 mx1.example.org. 115 IN MX 10 mx10.example.org. 116 mx1.example.org. IN AAAA 3ffe:501:ffff::1 117 IN A 192.0.2.1 118 mx10.example.org. IN AAAA 3ffe:501:ffff::2 119 IN A 192.0.2.2 121 But, every host may not support dual stack operation, some host entries 122 may have only IPv4 or IPv6 RRs: 124 example.org. IN MX 1 mx1.example.org. 125 IN MX 10 mx10.example.org. 126 mx1.example.org. IN AAAA 3ffe:501:ffff::1 127 mx10.example.org. IN A 192.0.2.1 129 In the following sections, how sender side operates with IPv4/IPv6 130 combined RR definitions (section 3), and how receiver side should define 131 RRs to keep interoperability with both IPv4 and IPv6 Internet (section 132 4) are considerd. 134 3. SMTP sender algorithm in a dual-stack environment 136 In a dual-stack environment MX records for a domain resemble the 137 following: 139 example.org. IN MX 1 mx1.example.org. 140 IN MX 10 mx10.example.org. 141 mx1.example.org. IN A 192.0.2.1 ; dual-stack 142 IN AAAA 3ffe:501:ffff::1 143 mx10.example.org. IN AAAA 3ffe:501:ffff::2 ; IPv6 only 145 For a single MX record there are many possible final states, including: 146 (a) one or more A records for the IPv4 destination, (b) one or more AAAA 147 records for the IPv6 destination, (c) a mixture of A and AAAA records. 148 Because multiple MX records may be defined using different preference 149 values, multiple addresses based on multiple MX's must be traversed. 150 Domains without MX records and failure recovery cases must be handled 151 properly as well. 153 ^L 155 DRAFT SMTP in dual stack environments January 2004 157 The algorithm for an SMTP sender is basically the same as that for an 158 IPv4-only sender, but it now includes AAAA lookups of MX records for 159 SMTP-over-IPv6 delivery. IPv4/v6 dual stack destinations should be 160 treated just like multihomed destinations as described in RFC2821 161 [Klensin, 2001] section 5. When there is no reachable destionation 162 address record found (for example, the sender MTA is IPv4 only and there 163 are no A records available) the case should be treated just like MX 164 records without address records, and deliveries should never fail 165 because of no known address if other addresses are available related to 166 other MX records. 168 ; if the sender MTA is IPv4 only, email delivery to a.example.org 169 ; should fail with the same error as deliveries to b.example.org. 170 a.example.org. IN MX 1 mx1.a.example.org. 171 mx1.a.example.org. IN AAAA 3ffe:501:ffff::1 ; IPv6 only 172 b.example.org. IN MX 1 mx1.b.example.org. 173 mx1.b.example.org. IN HINFO "NO ADDRESS RECORDS" 175 An algorithm for a dual-stack SMTP sender is as follows: 177 (1) Lookup the MX record for the destination domain. If a CNAME record 178 is returned, go to the top of step (1) with replacing the 179 destination domain by the query's result. If any MX records are 180 returned, go to step (2) with the query's result (explicit MX). If 181 NO_DATA (i.e. empty answer with NOERROR(0) RCODE) is returned, 182 there is no MX record but the name is valid. Assume that there is 183 a record like "name. IN MX 0 name." (implicit MX) and go to step 184 (3). If HOST_NOT_FOUND (i.e. empty answer with NXDOMAIN(3) RCODE) 185 is returned, there is no such domain. Raise a permanent email 186 delivery failure. Finish. 188 (2) Compare each host name in MX records with the name of sending host. 189 If there is a record which has the same name, drop MX records which 190 have equal to or larger than preference value of the matched MX 191 record (including itself). If multiple MX records remain, sort the 192 MX records in ascending order based on their preference values. 193 Loop over steps (3) to (9) on each host name in MX records in a 194 sequence. If no MX records remain, the sending host must be the 195 primary MX host. Other routing rule should be applied. Finish. 197 (3) If the sending MTA has IPv4 capability, lookup the A record. Keep 198 the resulting address until step (5). 200 (4) If the sending MTA has IPv6 capability, lookup the AAAA record. 202 NOTE: IPv6 addresses for hosts defined by MX records may be 203 informed in additional information section of DNS querie's result 204 as well as IPv4 addresses. If there is no additional address 205 information for the MX hosts, separate queries for A or AAAA 206 records should be sent. There is no way to query A and AAAA 207 records at once in current DNS implementation. 209 ^L 211 DRAFT SMTP in dual stack environments January 2004 213 (5) If there is no A or AAAA record present, try the next MX record (go 214 to step (3)). Note that the next MX record could have the same 215 preference. 217 NOTE: If one or more address records are found, some MTA 218 implementation may sort addresses based on the implementation's 219 preference of A or AAAA records. To encourage the transition from 220 IPv4 SMTP to IPv6 SMTP, AAAA records should take precedence. But 221 this type of sorting is optional. 223 (6) For each of the addresses, loop over steps (7) to (9). 225 (7) Try to make a TCP connection to the destination's SMTP port (25). 226 The client needs to follow timeouts documented in RFC2821 section 227 4.5.3.2. If successful, go to step (9). 229 (8) If unsuccessful and there is another available address, try the 230 next available address. Go to step (7). If all addresses are not 231 reachable and if a list of MX records is being traversed, try the 232 next MX record (go to step (3)). If there is no list of MX 233 records, or if the end of the list of MX records has been reached, 234 raise a temporary email delivery failure. Finish. 236 (9) Attempt to deliver the e-mail over the connection established, as 237 specified in RFC2821 [Klensin, 2001] . If a transient failure 238 condision reported, try the next MX record (go to step (3)). If an 239 error condition reported, raise a permanent email delivery error, 240 and further MX records are not tried. Finish. If successful, SMTP 241 delivery has succeeded. Finish. 243 4. MX configuration in the recipient domain 245 4.1. Ensuring reachability for both protocol versions 247 If a site has dual-stack reachability, the site SHOULD configure both A 248 and AAAA records for its MX hosts (NOTE: MX hosts can be outside of the 249 site). This will help both IPv4 and IPv6 senders to reach the site 250 efficiently. 252 4.2. Reachability between the primary and secondary MX 254 When registering MX records in a DNS database in a dual-stack 255 environment, reachability between MX hosts must be considered carefully. 256 Suppose all inbound email is to be gathered at the primary MX host, 257 "mx1.example.org.": 259 example.org. IN MX 1 mx1.example.org. 260 IN MX 10 mx10.example.org. 261 IN MX 100 mx100.example.org. 263 If "mx1.example.org" is an IPv6-only node, and the others are IPv4-only 265 ^L 267 DRAFT SMTP in dual stack environments January 2004 269 nodes, there is no reachability between the primary MX host and the 270 other MX hosts. When email reaches one of the lower MX hosts, it cannot 271 be relayed to the primary MX host based on MX preferencing mechanism, 272 therefore mx1.example.org will not be able to collect all the emails 273 (unless there is another transport mechanism(s) between lower-preference 274 MX hosts and mx1.example.org). 276 ; This configuration is troublesome. 277 ; No secondary MX can reach mx1.example.org. 278 example.org. IN MX 1 mx1.example.org. ; IPv6 only 279 IN MX 10 mx10.example.org. ; IPv4 only 280 IN MX 100 mx100.example.org. ; IPv4 only 282 The easiest possible configuration is to configure the primary MX host 283 as a dual-stack node. By doing so, secondary MX hosts will have no 284 problem reaching the primary MX host. 286 ; This configuration works well. 287 ; The secondary MX hosts are able to relay email to the primary MX host 288 ; without any problems. 289 example.org. IN MX 1 mx1.example.org. ; dual-stack 290 IN MX 10 mx10.example.org. ; IPv4 only 291 IN MX 100 mx100.example.org. ; IPv6 only 293 It may not be needed that the primary MX host and lower MX hosts reach 294 directly one another with IPv4 or IPv6 transport. For example, it is 295 possible to establish a routing path with UUCP or an IPv4/v6 translator. 296 It is also possible to drop messages into single mailbox with shared 297 storage using NFS or something else offered by a dual-stack server. It 298 is receiver site's matter that all messages delivered to each MX hosts 299 must be reached to recipient's mail drop. In such cases, dual-stack MX 300 host may not be listed in the MX list. 302 5. Operational experience 304 Many of the existing IPv6-ready MTA's appear to work in the way 305 documented in section 3. 307 There were, however, cases where IPv6-ready MTA's were confused by 308 broken DNS servers. When attempting to obtain a canonical hostname, 309 some broken name servers return SERVFAIL (RCODE 2), a temporary failure, 310 on AAAA record lookups. Upon this temporary failure, the email is 311 queued for a later attempt. In the interest of IPv4/v6 312 interoperability, these broken DNS servers should be fixed. A draft by 313 Yasuhiro Morishita [Morishita, 2003] has more detail on 314 misconfigured/misbehaving DNS servers and their bad sideeffects. 316 ^L 318 DRAFT SMTP in dual stack environments January 2004 320 6. Open issues 322 o How should scoped addresses (i.e. link-local addresses) in email 323 addresses be interpreted on MTA's? We suggest prohibiting the use of 324 IPv6 address literals in source routes (Scoped addresses should not 325 appear on the global DNS database). 327 o The document should really be integrated into RFC2821 [Klensin, 2001] 328 (i.e. RFC2821 should talk about IPv6 cases). 330 7. Security considerations 332 It could be problematic if the route-addr email address format is used 333 across multiple scope zones. MTA's would need to reject email with 334 improper route-addr email address formats. 336 References 338 Hagino, 2001. 339 Jun-ichiro Hagino and Hal Snyder, "IPv6 multihoming support at site exit 340 routers" in RFC3178 (October 2001). ftp://ftp.isi.edu/in- 341 notes/rfc3178.txt. 343 St.Johns, 1993. 344 M. St.Johns, "Identification Protocol" in RFC1413 (January 1993). 345 ftp://ftp.isi.edu/in-notes/rfc1413.txt. 347 Thomson, 1995. 348 S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in 349 RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.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 Morishita, 2003. 360 Y. Morishita and T. Jinmei, "Common Misbehavior against DNS Queries for 361 IPv6 Addresses" in draft-morishita-dnsop-misbehavior-against-aaaa-00.txt 362 (June 2003). work in progress material. 364 Change history 366 00 -> 01 367 Corrected the email address notation for source-routed emails, 368 based on a comment from Gregory Neil Shapiro. 370 ^L 372 DRAFT SMTP in dual stack environments January 2004 374 01 -> 02 375 Change a reference to refer to RFC2822, not 822. Used 376 "example.org", not "sample.org". These changes were based on 377 comments from Arnt Gulbrandsen. Added an ``Operational 378 experiences'' section. Clarified the case where an MX record 379 points to a CNAME record, based on comments from Mohsen Souissi. 381 02 -> 03 382 In some cases, IPv6-ready MTA's are troubled by incorrect DNS 383 server responses for AAAA queries. This change was based on 384 comments from Gregory Neil Shapiro. 386 03 -> 04 387 Grammar cleanups by JJ Behrens. More text on the delivery error 388 cases. 390 04 -> 05 391 Change title, suggested by Alain Durand. Limit the scope of the 392 document to dual stack environment (interoperation of IPv6-only 393 cloud and IPv4-only cloud is out of scope). 395 05 -> 06 396 Section on summary of IPv4 MX operation is deleted (Replaced by 397 Introduction). Clarify on CNAME chain. Cleanups on sender's 398 algorithm. Suggested by Patrik Faltstrom. 400 06 -> 07 401 Site local address is being obsoleted in IPv6 wg, so remove 402 reference to site-locals. Reflect comments from John C Klensin: 403 fixes to sending rules, correct route-addr issues. Reflect 404 comments from Michael A. Patton: HELO on connection via translator. 405 Reflect comments from Robert Elz. 407 07 -> 08 408 Refer a draft by Yasuhiro Morishita. 410 Acknowledgements 412 This draft was written based on discussions with Japanese IPv6 users and 413 help from the WIDE research group. Here is a (probably incomplete) list 414 of people who contributed to the draft: Gregory Neil Shapiro, Arnt 415 Gulbrandsen, Mohsen Souissi, JJ Behrens, John C Klensin, Michael A. 416 Patton, and Robert Elz. 418 Author's address 420 ^L 422 DRAFT SMTP in dual stack environments January 2004 424 Motonori NAKAMURA 425 Center for Information and Multimedia Studies, Kyoto University 426 Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN 427 Tel: +81-75-753-9063 428 Fax: +81-75-753-9056 429 Email: motonori@media.kyoto-u.ac.jp 431 Jun-ichiro itojun HAGINO 432 Research Laboratory, Internet Initiative Japan Inc. 433 1-105, Kanda Jinbo-cho, 434 Chiyoda-ku,Tokyo 101-0051, JAPAN 435 Tel: +81-3-5205-6464 436 Fax: +81-3-5205-6466 437 Email: itojun@iijlab.net 439 ^L