idnits 2.17.1 draft-oreirdan-rosenwald-ipv6mail-transition-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-oreirdan-rosenwald-ipv6-mail-transition-00', but the file name used is 'draft-oreirdan-rosenwald-ipv6mail-transition-00' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 200: '...ervice Providers SHOULD offer pilot IP...' RFC 2119 keyword, line 202: '... services MAY be provided via IPv6 t...' RFC 2119 keyword, line 206: '...2: Organizations SHOULD arrange for IP...' RFC 2119 keyword, line 208: '...ing email servers in this phase SHOULD...' RFC 2119 keyword, line 213: '...3: Organizations MAY provide IPv6-base...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 11, 2011) is 4672 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4472' is mentioned on line 209, but not defined == Unused Reference: 'RFC1939' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC1957' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC2449' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC2821' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC5211' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC6186' is defined on line 405, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Lord 3 Internet-Draft M. O'Reirdan 4 Intended status: Informational J. Rosenwald 5 Expires: January 12, 2012 Comcast 6 July 11, 2011 8 Recommendations for the transition of email services from IPv4 to IPv6 9 for Internet Service Providers 10 draft-oreirdan-rosenwald-ipv6-mail-transition-00 12 Abstract 14 This document contains recommendations on how providers of email 15 services can effect and manage the transition of email services from 16 IPv4 to IPv6. It is expected that this will be effected over a 17 period of years and it is unlikely that any transition will 18 completely exclude the ongoing possibility of using IPv4 as a 19 transport mechanism for email. This provides one possible plan for 20 transitioning email services on the Internet from a predominantly 21 IPv4-based connectivity model to a predominantly IPv6-based 22 connectivity model. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 12, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Key Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Introduction and Problem Statement . . . . . . . . . . . . . . 4 72 3. Important Notice of Limitations and Scope . . . . . . . . . . 5 73 4. A Phased Transition Model . . . . . . . . . . . . . . . . . . 5 74 5. Preparation Phase--Present to January 2013 . . . . . . . . . . 6 75 6. Transition Phase--February 2013 to January 2014 . . . . . . . 6 76 7. Post Transition Phase--February 2014 to the future . . . . . . 7 77 8. SMTP Issues raised by transition to IPv6 . . . . . . . . . . . 7 78 9. Webmail issues raised by transition to IPv6 . . . . . . . . . 7 79 10. POP3 issues raised by transition to IPv6 . . . . . . . . . . . 7 80 11. Issues specific to the handling of email inbound including 81 abuse issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 12. Issues specific to the handling of email outbound 83 including abuse issues . . . . . . . . . . . . . . . . . . . . 8 84 13. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9 86 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 87 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 88 17. Informative references . . . . . . . . . . . . . . . . . . . . 10 89 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 10 90 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Key Terminology 95 This section defines the key terms used in this document. 97 1.1. Email 99 Email is a method of exchanging digital messages from an author to 100 one or more recipients. 102 1.2. Web mail 104 A service which offers web based access to email services which would 105 otherwise be accessed by dedicated email programs running on the 106 device used to access the email. 108 1.3. Host 110 An end user's host, or computer, as used in the context of this 111 document, is intended to refer to a computing device that connects to 112 the Internet. This encompasses devices used by Internet users such 113 as personal computers, including laptops, desktops, and netbooks, as 114 well as mobile phones, smart phones, home gateway devices, and other 115 end user computing devices which are connected or can connect to the 116 public Internet and/or private IP networks. 118 Increasingly, other household systems and devices contain embedded 119 hosts which are connected to or can connect to the public Internet 120 and/or private IP networks. However, these devices may not be under 121 interactive control of the Internet user, such as may be the case 122 with various smart home and smart grid devices. 124 1.4. SMTP 126 As defined in RFC2821 128 1.5. POP 130 As defined in RFC1939 and updated by RFCs 1957, 2449 and 6186 132 2. Introduction and Problem Statement 134 With the depletion of IPv4 address space and the transition of 135 Internet infrastructure to IPv6, it is necessary to address the way 136 in which email services can be transitioned from an IPv4 transport to 137 that of IPv6. It is anticipated that IPv4 will continue for a long 138 time as a major transport mechanism for email services of all sorts. 139 There are significant issues to be addressed around the matter of 140 abuse in an IPv6 based environment which have been addressed and 141 largely resolved when operating using IPv4 as a transport mechanism. 142 The successful resolution of abuse issues may well be a key 143 limitation on the transition of email to an IPv6 environment from the 144 point of view of Internet Service providers. 146 3. Important Notice of Limitations and Scope 148 The issues of abuse specific to IPv6 are not yet fully resolved and 149 will need much additional work. The consideration given to abuse 150 issues here should be considered as preliminary and incomplete. 152 4. A Phased Transition Model 154 It is not reasonable to specify the changes that each and every email 155 system connected to the Internet must undergo in order to achieve the 156 desired transition, as the number of connected systems precludes 157 creating one plan that contains such a level of detail. Further, 158 while there are common scenarios that may be specified for 159 transitioning individual email systems, the specific timeline and 160 mechanisms utilized for a given email system will be unique. Despite 161 these challenges, it is necessary to coordinate expectations on an 162 overall basis so that Internet-wide email services are maintained 163 throughout the transition. This document specifies a three-phase 164 transition plan that includes preparation, transition, and post- 165 transition phases, and delineates the necessary activities within 166 each phase based on the role that an organization plays in the 167 provision and use of email services. 169 An important distinction made in this transition plan is identifying 170 the explicit requirement for existing end-site organizations to add 171 IPv6-based connectivity to their email servers during a transition 172 phase. An accelerated adoption of IPv6 for email servers enables new 173 organizations in the post-transition phase to be connected to the 174 Internet only via IPv6 and still have access to the overall set of 175 email servers. 177 For nearly every organization, the task of IPv6-enabling their email 178 servers is far easier than undertaking an organization-wide adoption 179 of IPv6. Still, the requirement for existing Internet-connected 180 organizations to add IPv6 connectivity (even to a small number of 181 email systems) will be a significant hurdle and require a level of 182 effort that may not be achievable given the lack of compelling 183 additional benefits to these organizations [RFC1669]. This 184 transition plan presumes that "connectivity is its own reward" 185 [RFC1958] and that there still exists a sufficient level of 186 cooperation among Internet participants to make this evolution 187 possible. 189 The three proposed phases are: Preparation Phase, Transition Phase, 190 and Post-Transition Phase. 192 5. Preparation Phase--Present to January 2013 194 In the Preparation Phase, Service Providers pilot test their IPv6 195 email services, and end-site organizations prepare to provide email 196 services via IPv6-based connectivity while continuing to provide 197 email services via IPv4 connectivity. During the Preparation Phase, 198 the following principles apply: 200 PREP1: Service Providers SHOULD offer pilot IPv6-based email service 201 to their Internet customers for outbound sending. IPv6-based email 202 services MAY be provided via IPv6 transition mechanisms (such as 203 those described in [RFC4213], for example) or via native IPv6 network 204 service. 206 PREP2: Organizations SHOULD arrange for IPv6-based Internet 207 connectivity for any Internet facing email servers sending or 208 receiving email. Internet-facing email servers in this phase SHOULD 209 use separate service names per [RFC4472] to avoid impact to 210 production IPv4-based services unless the organization supports 211 production IPv6 connectivity. 213 PREP3: Organizations MAY provide IPv6-based email services to 214 internal user communities. 216 6. Transition Phase--February 2013 to January 2014 218 In the Transition Phase, Service Providers offer production IPv6 and 219 IPv4 services to their Internet customers. End-site organizations 220 provide Internet-facing services in a production manner via IPv6- 221 based connectivity in addition to IPv4-based connectivity. During 222 the Transition Phase, the following principles apply: 224 TRANS1: Service Providers MUST offer IPv6-based email service to 225 their Internet customers. IPv6-based email service SHOULD be via 226 native IPv6 network service but MAY be via IPv6 transition mechanisms 227 if necessary. 229 TRANS2: Organizations MUST arrange for IPv6-based Internet 230 connectivity for any Internet-facing servers (e.g., web, email, and 231 domain name servers). Internet-facing IPv6 servers SHOULD be treated 232 as production by the organization, and SHOULD be treated as 233 production by other Internet organizations. 235 TRANS3: Organizations SHOULD provide IPv6-based email service to 236 their internal user communities. 238 7. Post Transition Phase--February 2014 to the future 240 In the Post-Transition Phase, end-site organizations MUST provide all 241 email services via IPv6-based connectivity, thus allowing for new 242 Internet customers connected solely by IPv6. During the Post- 243 Transition Phase, the following principles apply: 245 POST1: Service Providers MUST offer IPv6-based email service to their 246 Internet customers. IPv6-based email service SHOULD be via native 247 IPv6 network service. 249 POST2: Organizations MUST arrange for IPv6-based Internet 250 connectivity for any Internet-facing email servers. Internet-facing 251 IPv6 email servers MUST be treated as production by the organization, 252 and SHOULD be treated as production by other Internet organizations. 254 POST3: Organizations SHOULD provide IPv6-based email service to 255 internal user communities. 257 POST4: Service Providers MAY continue to offer IPv4-based email 258 service to their Internet customers. Organizations MAY continue to 259 use IPv4-based email service. 261 8. SMTP Issues raised by transition to IPv6 263 This section will cover issues around the use of SMTP in an IPv6 264 based infrastructure. 266 9. Webmail issues raised by transition to IPv6 268 This section will cover issues around the use of Webmail in an IPv6 269 based infrastructure. 271 10. POP3 issues raised by transition to IPv6 273 This section will cover issues around the use of POP3 in an IPv6 274 based infrastructure. 276 11. Issues specific to the handling of email inbound including abuse 277 issues 279 Domain Authentication will be required and will be utilizing the 280 mechanisms outlined in RFC4871, RFC5585 and RFC5617 282 Consideration should be given to a white-list environment for a 283 limited number of email servers which are verified as belonging to 284 authorized sources of email. It is likely that these would be the 285 email servers of large ISPs, well known email senders such as major 286 Email service providers and other verified sources 288 Given the scale of the IPv6 address space, the possibility that a 289 connection exhaustion scenario may develop where the number of 290 attempted connections to an individual email service may overwhelm 291 its ability to provide service. This may occur either deliberately 292 as part of an abusive scenario or inadvertently due to 293 misconfiguration. 295 Common filtering techniques that are critical for early decision 296 making such as real-time blocklists and IP reputation will need to be 297 amended for practical use in an IPv6 environment. Other reputation 298 keys such as CIDR reputation and domain reputation should be 299 considered. 301 12. Issues specific to the handling of email outbound including abuse 302 issues 304 Submitting of unauthenticated port 25 mail to outbound IPv6 email 305 servers MUST be prohibited. User authentication MUST be required to 306 allow users to submit email for delivery. 308 In environments where IP reputation is tracked for outbound 309 customers, this is likely to occur for ISPs that do not require 310 authentication for sending email outbound. Consideration will have 311 to be made for tracking reputation per CIDR. CIDR reputation would 312 continue to track reputation at the lowest unit currently maintained 313 which is the customer residence. 315 Public announcement and aggregation of IPv6 addresses into the 316 delegated CIDR blocks will be required for the purpose of identity 317 identification. CIDR reputation can then be applied to the whole 318 entity. 320 Throttling, particularly when off-net sending is allowed, should be 321 considered. 323 Utilization of 6to4 conversion (modem to server (6) and server to 324 external server (4)) can be an intermediate step as described above. 325 Utilization of NAT technologies may also obscure the source IP 326 address. 328 Given the scale of the IPv6 address space, the possibility that a 329 connection exhaustion scenario may develop where the number of 330 attempted connections to an individual email service may overwhelm 331 its ability to provide service. This may occur either deliberately 332 as part of an abusive scenario or inadvertently due to 333 misconfiguration. 335 13. Security Considerations 337 This document does not address any security issues inherent in IPv6 338 itself. It acknowledges that there are as yet unresolved abuse 339 issues specific to deploying email infrastructures based on an IPv6 340 transport. Abuse issues includes spam, phishing and spoofing of 341 email addresses. 343 14. Privacy Considerations 345 This document describes at a high level activities that ISPs should 346 be sensitive to, where the collection or communication of PII may be 347 possible. In addition, when performing this transition, ISPs should 348 be careful to protect any PII collected whether deliberately or 349 inadvertently. 351 As noted, any sharing of data from the user to the ISP and/or 352 authorized third parties should be done on an opt-in basis. 353 Additionally the ISP and or authorized third parties should clearly 354 state what data will be shared and with whom the data will be shared 355 with. 357 Lastly,there my be legal requirements in particular legal 358 jurisdictions concerning how long any subscriber-related or other 359 data is retained, of which an ISP operating in such a jurisdiction 360 should be aware and with which an ISP should comply. 362 15. IANA Considerations 364 There are no IANA considerations in this document. 366 16. Acknowledgements 368 The authors wish to acknowledge the following individuals and groups 369 for performing a detailed review of this document and/or providing 370 comments and feedback that helped to improve and evolve this 371 document: 373 None as yet 375 Large section of this document are based on RFC5211 "An Internet 376 Transition Plan" authored by John Curran which outlines an overall 377 transition plan for the Internet from IPv4 to IPv6. 379 17. Informative references 381 [RFC1669] Curran, J., "Market Viability as a IPng Criteria", 382 RFC 1669, August 1994. 384 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 385 STD 53, RFC 1939, May 1996. 387 [RFC1957] Nelson, R., "Some Observations on Implementations of the 388 Post Office Protocol (POP3)", RFC 1957, June 1996. 390 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 391 RFC 1958, June 1996. 393 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 394 Mechanism", RFC 2449, November 1998. 396 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 397 April 2001. 399 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 400 for IPv6 Hosts and Routers", RFC 4213, October 2005. 402 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, 403 July 2008. 405 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 406 Submission/Access Services", RFC 6186, March 2011. 408 Appendix A. Document Change Log 410 [RFC Editor: This section is to be removed before publication] 411 -01 version: 413 o -01 version published 415 Appendix B. Open Issues 417 [RFC Editor: This section is to be removed before publication] 419 No open issues to date 421 Authors' Addresses 423 Heather Lord 424 Comcast Cable Communications 425 One Comcast Center 426 1701 John F. Kennedy Boulevard 427 Philadelphia, PA 19103 428 US 430 Email: heather_lord@cable.comcast.com 431 URI: http://www.comcast.com 433 Michael O'Reirdan 434 Comcast Cable Communications 435 One Comcast Center 436 1701 John F. Kennedy Boulevard 437 Philadelphia, PA 19103 438 US 440 Email: michael_oreirdan@cable.comcast.com 441 URI: http://www.comcast.com 443 Jordan Rosenwald 444 Comcast Cable Communications 445 One Comcast Center 446 1701 John F. Kennedy Boulevard 447 Philadelphia, PA 19103 448 US 450 Email: jordan_rosenwald@cable.comcast.com 451 URI: http://www.comcast.com