Internet Architecture Board D. Thaler Internet-Draft Microsoft Intended status: Informational October 5, 2015 Expires: April 7, 2016 Designing for Transition draft-thaler-transition-principles-00.txt Abstract Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions, throughout the protocol stack, from one protocol or technology to another. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions, and thus some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and also summarizes what makes for a good transition plan. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 7, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Thaler Expires April 7, 2016 [Page 1] Internet-Draft Transition Principles October 2015 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Transition vs. Co-existence . . . . . . . . . . . . . . . . . 4 3. Translation/Adaptation Location . . . . . . . . . . . . . . . 4 4. Translation Plans . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Informative References . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction A "transition" is "the process or period of changing from one state or condition to another. There are several types of such transitions, including both technical transitions (e.g., changing a protocol or deploying an extension) and organizational transitions (e.g., changing what organization manages the IETF web site, or the RFC production center). This document focuses solely on technical transitions, although some principles might apply to other types as well. There have been many IETF and IAB RFCs and IAB statements discussing transitions of various sorts. Most are protocol-specific documents about specific transitions. For example, some relevant ones in which the IAB has been involved include: o IAB RFC 3424 [RFC3424] recommended that any technology for so- called "unilateral self-address fixing (UNSAF)" across NATs include an exit strategy/plan to transition away from such a mechanism. Since the IESG, not the IAB, approves IETF documents, the IESG thus became the body to enforce (or not) such a requirement. o IAB RFC 4690 [RFC4690] gave recommendations around internationalized domain names. It discussed issues around the process of transitioning to new versions of Unicode, and this resulted in the creation of the IETF Precis WG to address this problem. o The IAB statement on "Follow-up-work on NAT-PT" [IabIpv6TransitionStatement] pointed out gaps at the time in Thaler Expires April 7, 2016 [Page 2] Internet-Draft Transition Principles October 2015 transitioning to IPv6, and this resulted in the rechartering of the IETF Behave WG to solve this problem. More recently, the IAB has done work on more generally applicable principles, including two RFCs. IAB RFC 5218 [RFC5218] on "What Makes for a Successful Protocol?" studied specifically what factors contribute to, and detract from, the success of a protocol and it made a number of recommendations. It discussed two types of transitions: "initial success" (the transition to the technology) and extensibility (the transition to updated versions of it). The principles and recommendations in that document are generally applicable to all technical transitions. Some important principles included: 1. Incentive: Transition is easiest when the benefits come to those bearing the costs. That is, the benefits should outweigh the costs at *each* entity. Some successful cases did this by providing incentives (e.g., tax breaks), or by reducing costs (e.g., freely available source), or by imposing costs of not transitioning (e.g., regulation), or even by narrowing the scenarios of applicability to just the cases where benefits do outweigh costs. 2. Incremental Deployability: Backwards compatibility makes transition easier. Furthermore, transition is easiest when changing only one entity still benefits that entity. In the easiest case, the benefit immediately outweighs the cost and so entities are naturally incented to transition. More commonly, the benefits only outweigh the costs once a significant number of other entities also transition. Unfortunately, in such cases, the natural incentive is often to delay transitioning. 3. Total Cost: Don't underestimate the cost of things other than the hardware/software itself. For example, operational tools and processes, personnel training, business model (accounting/ billing) dependencies, and legal (regulation, patents, etc.) costs all add up. 4. Extensibility: Design for extensibility so that things can be fixed up later. IAB RFC 7305 [RFC7305] reported on a IAB workshop on Internet Technology Adoption and Transition (ITAT). Like RFC 5218, this workshop also discussed economic aspects of transition, not just technical aspects. Some important observations included: Thaler Expires April 7, 2016 [Page 3] Internet-Draft Transition Principles October 2015 1. Early-Adopter Incentives: Part of Bitcoin's strategy was extra incentives for early adopters. That is, providing a long-term advantage to early adopters can help stimulate transition even when the initial costs outweigh the initial benefit. 2. Policy Partners: Policy-making organizations of various sorts (RIRs, ICANN, etc.) can be important partners in enabling and facilitating transition. The remainder of this document continues the discussion in those two RFCs and provides some additional thoughts on the topic of transition strategies and plans. 2. Transition vs. Co-existence We need to distinguish between a strict "flag-day" style transition where an old mechanism is immediately replaced with a new mechanism, vs. a looser co-existence based approach where transition proceeds in stages where a new mechanism is first added alongside an existing one for some overlap period, and then the old mechanism is removed at a later stage. When a new mechanism is backwards compatible with an existing mechanism, transition is easiest, and the difference between the two types of transition is not particularly significant. However, when no backwards compatibility exists (such as in the IPv4 to IPv6 transition), a transition plan must choose either a "flag day" or a period of co-existence. When a large number of entities are involved, a flag day becomes impractical. Coexistence, on the other hand, involves additional costs of maintaining two separate mechanisms during the overlap period which could be quite long. Furthermore, the longer the overlap period, the more the old mechanism might get further deployment and thus increase the overall pain of transition. Often the decision between a "flag day" and a sustained co-existence period may be difficult, such as in the case of IDNA2008 [RFC5891] [RFC5895] and Unicode TR46 [TR46]. 3. Translation/Adaptation Location A translation or adaptation layer is often required if the old and new mechanisms are not interoperable. Care must be taken when determining where such a translator is best placed. Requiring a translator in the middle of the path can hamper end-to- end security and reliability. For example, see the discussion of network-based filtering in [I-D.iab-filtering-considerations]. Thaler Expires April 7, 2016 [Page 4] Internet-Draft Transition Principles October 2015 On the other hand, requiring a translation layer within an endpoint can be a resource issue in some cases, such as if the endpoint could be a constrained node [RFC7228]. Any transition strategy for a non-backward-compatible mechanism should include a discussion of where it is placed and a rationale. 4. Translation Plans A good transition plan includes at least the following components: 1. An explanation of incentives for each entity involved 2. A description of transition phases. For example, there might be pilot, co-existence, deprecation, and removal phases, for a transition from one technology to another incompatible one. 3. A proposed timeline 4. A way to effectively communicate the proposed plan to the entities affected, and incorporate their feedback 5. Security Considerations This document discusses attributes of protocol transitions. Some types of transition can adversely affect security or privacy. For example, requiring a translator in the middle of the path may hamper end-to-end security and privacy, since it creates an attractive target. For further discussion of some of these issues, see Section 5 of [I-D.iab-filtering-considerations]. 6. IANA Considerations This document requires no actions by the IANA. 7. Informative References [I-D.iab-filtering-considerations] Barnes, R., Cooper, A., Kolkman, O., and D. Thaler, "Technical Considerations for Internet Service Blocking and Filtering", draft-iab-filtering-considerations-07 (work in progress), July 2015. [IabIpv6TransitionStatement] IAB, "Follow-up work on NAT-PT", October 2007, . Thaler Expires April 7, 2016 [Page 5] Internet-Draft Transition Principles October 2015 [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, . [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, . [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, . [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, . [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, . [TR46] Unicode Consortium, "Unicode IDNA Compatibility Processing", June 2015, . Author's Address Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052 US Email: dthaler@microsoft.com Thaler Expires April 7, 2016 [Page 6]