idnits 2.17.1
draft-thaler-transition-principles-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:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 5, 2015) is 3125 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-09) exists of
draft-iab-filtering-considerations-07
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Architecture Board D. Thaler
3 Internet-Draft Microsoft
4 Intended status: Informational October 5, 2015
5 Expires: April 7, 2016
7 Designing for Transition
8 draft-thaler-transition-principles-00.txt
10 Abstract
12 Over the many years since the introduction of the Internet Protocol,
13 we have seen a number of transitions, throughout the protocol stack,
14 from one protocol or technology to another. Many protocols and
15 technologies were not designed to enable smooth transition to
16 alternatives or to easily deploy extensions, and thus some
17 transitions, such as the introduction of IPv6, have been difficult.
18 This document attempts to summarize some basic principles to enable
19 future transitions, and also summarizes what makes for a good
20 transition plan.
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at http://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on April 7, 2016.
39 Copyright Notice
41 Copyright (c) 2015 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 2. Transition vs. Co-existence . . . . . . . . . . . . . . . . . 4
58 3. Translation/Adaptation Location . . . . . . . . . . . . . . . 4
59 4. Translation Plans . . . . . . . . . . . . . . . . . . . . . . 5
60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
62 7. Informative References . . . . . . . . . . . . . . . . . . . 5
63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
65 1. Introduction
67 A "transition" is "the process or period of changing from one state
68 or condition to another. There are several types of such
69 transitions, including both technical transitions (e.g., changing a
70 protocol or deploying an extension) and organizational transitions
71 (e.g., changing what organization manages the IETF web site, or the
72 RFC production center). This document focuses solely on technical
73 transitions, although some principles might apply to other types as
74 well.
76 There have been many IETF and IAB RFCs and IAB statements discussing
77 transitions of various sorts. Most are protocol-specific documents
78 about specific transitions. For example, some relevant ones in which
79 the IAB has been involved include:
81 o IAB RFC 3424 [RFC3424] recommended that any technology for so-
82 called "unilateral self-address fixing (UNSAF)" across NATs
83 include an exit strategy/plan to transition away from such a
84 mechanism. Since the IESG, not the IAB, approves IETF documents,
85 the IESG thus became the body to enforce (or not) such a
86 requirement.
88 o IAB RFC 4690 [RFC4690] gave recommendations around
89 internationalized domain names. It discussed issues around the
90 process of transitioning to new versions of Unicode, and this
91 resulted in the creation of the IETF Precis WG to address this
92 problem.
94 o The IAB statement on "Follow-up-work on NAT-PT"
95 [IabIpv6TransitionStatement] pointed out gaps at the time in
96 transitioning to IPv6, and this resulted in the rechartering of
97 the IETF Behave WG to solve this problem.
99 More recently, the IAB has done work on more generally applicable
100 principles, including two RFCs.
102 IAB RFC 5218 [RFC5218] on "What Makes for a Successful Protocol?"
103 studied specifically what factors contribute to, and detract from,
104 the success of a protocol and it made a number of recommendations.
105 It discussed two types of transitions: "initial success" (the
106 transition to the technology) and extensibility (the transition to
107 updated versions of it). The principles and recommendations in that
108 document are generally applicable to all technical transitions. Some
109 important principles included:
111 1. Incentive: Transition is easiest when the benefits come to those
112 bearing the costs. That is, the benefits should outweigh the
113 costs at *each* entity. Some successful cases did this by
114 providing incentives (e.g., tax breaks), or by reducing costs
115 (e.g., freely available source), or by imposing costs of not
116 transitioning (e.g., regulation), or even by narrowing the
117 scenarios of applicability to just the cases where benefits do
118 outweigh costs.
120 2. Incremental Deployability: Backwards compatibility makes
121 transition easier. Furthermore, transition is easiest when
122 changing only one entity still benefits that entity. In the
123 easiest case, the benefit immediately outweighs the cost and so
124 entities are naturally incented to transition. More commonly,
125 the benefits only outweigh the costs once a significant number of
126 other entities also transition. Unfortunately, in such cases,
127 the natural incentive is often to delay transitioning.
129 3. Total Cost: Don't underestimate the cost of things other than the
130 hardware/software itself. For example, operational tools and
131 processes, personnel training, business model (accounting/
132 billing) dependencies, and legal (regulation, patents, etc.)
133 costs all add up.
135 4. Extensibility: Design for extensibility so that things can be
136 fixed up later.
138 IAB RFC 7305 [RFC7305] reported on a IAB workshop on Internet
139 Technology Adoption and Transition (ITAT). Like RFC 5218, this
140 workshop also discussed economic aspects of transition, not just
141 technical aspects. Some important observations included:
143 1. Early-Adopter Incentives: Part of Bitcoin's strategy was extra
144 incentives for early adopters. That is, providing a long-term
145 advantage to early adopters can help stimulate transition even
146 when the initial costs outweigh the initial benefit.
148 2. Policy Partners: Policy-making organizations of various sorts
149 (RIRs, ICANN, etc.) can be important partners in enabling and
150 facilitating transition.
152 The remainder of this document continues the discussion in those two
153 RFCs and provides some additional thoughts on the topic of transition
154 strategies and plans.
156 2. Transition vs. Co-existence
158 We need to distinguish between a strict "flag-day" style transition
159 where an old mechanism is immediately replaced with a new mechanism,
160 vs. a looser co-existence based approach where transition proceeds in
161 stages where a new mechanism is first added alongside an existing one
162 for some overlap period, and then the old mechanism is removed at a
163 later stage.
165 When a new mechanism is backwards compatible with an existing
166 mechanism, transition is easiest, and the difference between the two
167 types of transition is not particularly significant. However, when
168 no backwards compatibility exists (such as in the IPv4 to IPv6
169 transition), a transition plan must choose either a "flag day" or a
170 period of co-existence. When a large number of entities are
171 involved, a flag day becomes impractical. Coexistence, on the other
172 hand, involves additional costs of maintaining two separate
173 mechanisms during the overlap period which could be quite long.
174 Furthermore, the longer the overlap period, the more the old
175 mechanism might get further deployment and thus increase the overall
176 pain of transition.
178 Often the decision between a "flag day" and a sustained co-existence
179 period may be difficult, such as in the case of IDNA2008 [RFC5891]
180 [RFC5895] and Unicode TR46 [TR46].
182 3. Translation/Adaptation Location
184 A translation or adaptation layer is often required if the old and
185 new mechanisms are not interoperable. Care must be taken when
186 determining where such a translator is best placed.
188 Requiring a translator in the middle of the path can hamper end-to-
189 end security and reliability. For example, see the discussion of
190 network-based filtering in [I-D.iab-filtering-considerations].
192 On the other hand, requiring a translation layer within an endpoint
193 can be a resource issue in some cases, such as if the endpoint could
194 be a constrained node [RFC7228].
196 Any transition strategy for a non-backward-compatible mechanism
197 should include a discussion of where it is placed and a rationale.
199 4. Translation Plans
201 A good transition plan includes at least the following components:
203 1. An explanation of incentives for each entity involved
205 2. A description of transition phases. For example, there might be
206 pilot, co-existence, deprecation, and removal phases, for a
207 transition from one technology to another incompatible one.
209 3. A proposed timeline
211 4. A way to effectively communicate the proposed plan to the
212 entities affected, and incorporate their feedback
214 5. Security Considerations
216 This document discusses attributes of protocol transitions. Some
217 types of transition can adversely affect security or privacy. For
218 example, requiring a translator in the middle of the path may hamper
219 end-to-end security and privacy, since it creates an attractive
220 target. For further discussion of some of these issues, see
221 Section 5 of [I-D.iab-filtering-considerations].
223 6. IANA Considerations
225 This document requires no actions by the IANA.
227 7. Informative References
229 [I-D.iab-filtering-considerations]
230 Barnes, R., Cooper, A., Kolkman, O., and D. Thaler,
231 "Technical Considerations for Internet Service Blocking
232 and Filtering", draft-iab-filtering-considerations-07
233 (work in progress), July 2015.
235 [IabIpv6TransitionStatement]
236 IAB, "Follow-up work on NAT-PT", October 2007,
237 .
240 [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for
241 UNilateral Self-Address Fixing (UNSAF) Across Network
242 Address Translation", RFC 3424, DOI 10.17487/RFC3424,
243 November 2002, .
245 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
246 Recommendations for Internationalized Domain Names
247 (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006,
248 .
250 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful
251 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
252 .
254 [RFC5891] Klensin, J., "Internationalized Domain Names in
255 Applications (IDNA): Protocol", RFC 5891,
256 DOI 10.17487/RFC5891, August 2010,
257 .
259 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
260 Internationalized Domain Names in Applications (IDNA)
261 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
262 .
264 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
265 Constrained-Node Networks", RFC 7228,
266 DOI 10.17487/RFC7228, May 2014,
267 .
269 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet
270 Technology Adoption and Transition (ITAT)", RFC 7305,
271 DOI 10.17487/RFC7305, July 2014,
272 .
274 [TR46] Unicode Consortium, "Unicode IDNA Compatibility
275 Processing", June 2015,
276 .
278 Author's Address
280 Dave Thaler
281 Microsoft
282 One Microsoft Way
283 Redmond, WA 98052
284 US
286 Email: dthaler@microsoft.com