GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8170

Internet Architecture Board (IAB) D. Thaler, Ed. Request for Comments: 8170 May 2017 Category: Informational ISSN: 2070-1721

     Planning for Protocol Adoption and Subsequent Transitions

Abstract

 Over the many years since the introduction of the Internet Protocol,
 we have seen a number of transitions throughout the protocol stack,
 such as deploying a new protocol, or updating or replacing an
 existing protocol.  Many protocols and technologies were not designed
 to enable smooth transition to alternatives or to easily deploy
 extensions; 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 it also summarizes what
 makes for a good transition plan.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Architecture Board (IAB)
 and represents information that the IAB has deemed valuable to
 provide for permanent record.  It represents the consensus of the
 Internet Architecture Board (IAB).  Documents approved for
 publication by the IAB are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc8170.

Copyright Notice

 Copyright (c) 2017 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
 to this document.

Thaler Informational [Page 1] RFC 8170 Planning for Transition May 2017

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 2.  Extensibility . . . . . . . . . . . . . . . . . . . . . . . .   4
 3.  Transition vs. Coexistence  . . . . . . . . . . . . . . . . .   5
 4.  Translation/Adaptation Location . . . . . . . . . . . . . . .   6
 5.  Transition Plans  . . . . . . . . . . . . . . . . . . . . . .   7
   5.1.  Understanding of Existing Deployment  . . . . . . . . . .   7
   5.2.  Explanation of Incentives . . . . . . . . . . . . . . . .   7
   5.3.  Description of Phases and Proposed Criteria . . . . . . .   8
   5.4.  Measurement of Success  . . . . . . . . . . . . . . . . .   8
   5.5.  Contingency Planning  . . . . . . . . . . . . . . . . . .   8
   5.6.  Communicating the Plan  . . . . . . . . . . . . . . . . .   9
 6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
 7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
 8.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  10
 9.  Informative References  . . . . . . . . . . . . . . . . . . .  10
 Appendix A.  Case Studies . . . . . . . . . . . . . . . . . . . .  14
   A.1.  Explicit Congestion Notification  . . . . . . . . . . . .  14
   A.2.  Internationalized Domain Names  . . . . . . . . . . . . .  15
   A.3.  IPv6  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   A.4.  HTTP  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
     A.4.1.  Protocol Versioning, Extensions, and 'Grease' . . . .  20
     A.4.2.  Limits on Changes in Major Versions . . . . . . . . .  20
     A.4.3.  Planning for Replacement  . . . . . . . . . . . . . .  21
 IAB Members at the Time of Approval . . . . . . . . . . . . . . .  22
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  22
 Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

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 protocols or
 deploying an extension) and organizational transitions (e.g.,
 changing what organization manages a web site).  This document
 focuses solely on technical transitions, although some principles
 might apply to other types as well.
 In this document, we use the term "transition" generically to apply
 to any of:
 o  adoption of a new protocol where none existed before,
 o  deployment of a new protocol that obsoletes a previous protocol,

Thaler Informational [Page 2] RFC 8170 Planning for Transition May 2017

 o  deployment of an updated version of an existing protocol, or
 o  decommissioning of an obsolete protocol.
 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 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 Working Group (WG) to
    address this problem.
 o  The IAB statement on "Follow-up work on NAT-PT"
    [IabIpv6TransitionStatement] pointed out gaps at the time in
    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 at all relevant entities.

Thaler Informational [Page 3] RFC 8170 Planning for Transition May 2017

 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, 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: It is important to consider costs that go beyond the
     core hardware and software, such as operational tools and
     processes, personnel training, business model (accounting/
     billing) dependencies, and legal (regulation, patents, etc.)
     costs.
 4.  Extensibility: Design for extensibility [RFC6709] so that things
     can be fixed up later.
 IAB RFC 7305 [RFC7305] reported on an 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:
 1.  Early-Adopter Incentives: Part of Bitcoin's strategy was extra
     incentives for early adopters compared to late 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
     (Regional Internet Registries (RIRs), ICANN, etc.) can be
     important partners in enabling and facilitating transition.
 The remainder of this document continues the discussion started in
 those two RFCs and provides some additional thoughts on the topic of
 transition strategies and plans.

2. Extensibility

 Many protocols are designed to be extensible, using mechanisms such
 as options, version negotiation, etc., to ease the transition to new
 features.  However, implementations often succumb to commercial
 pressures to ignore this flexibility in favor of performance or
 economy, and as a result such extension mechanisms (e.g., IPv6 Hop-
 by-Hop Options) often experience problems in practice once they begin
 to be used.  In other cases, a mechanism might be put into a protocol
 for future use without having an adequate sense of how it will be
 used, which causes problems later (e.g., SNMP's original 'security'

Thaler Informational [Page 4] RFC 8170 Planning for Transition May 2017

 field, or the IPv6 Flow Label).  Thus, designers need to consider
 whether it would be easier to transition to a new protocol than it
 would be to ensure that an extension point is correctly specified and
 implemented such that it would be available when needed.
 A protocol that plans for its own eventual replacement during its
 design makes later transitions easier.  Developing and testing a
 design for the technical mechanisms needed to signal or negotiate a
 replacement is essential in such a plan.
 When there is interest in translation between a new mechanism and an
 old one, complexity of such translation must also be considered.  The
 major challenge in translation is for semantic differences.  Often,
 syntactic differences can be translated seamlessly; semantic ones
 almost never.  Hence, when designing for translatability, syntactic
 and semantic differences should be clearly documented.
 See RFC 3692 [RFC3692] and RFC 6709 [RFC6709] for more discussion of
 design considerations for protocol extensions.

3. Transition vs. Coexistence

 There is an important distinction between a strict "flag day" style
 transition where an old mechanism is immediately replaced with a new
 mechanism, vs. a looser coexistence-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 because different parties can
 transition at different times.  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
 coexistence.  When a large number of entities are involved, a flag
 day becomes impractical or even impossible.  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 coexistence
 period may be complicated when differing incentives are involved
 (e.g., see the case studies in the Appendix).
 Some new protocols or protocol versions are developed with the intent
 of never retiring the protocol they intend to replace.  Such a

Thaler Informational [Page 5] RFC 8170 Planning for Transition May 2017

 protocol might only aim to address a subset of the use cases for
 which an original is used.  For these protocols, coexistence is the
 end state.
 Indefinite coexistence as an approach could be viable if removal of
 the existing protocol is not an urgent goal.  It might also be
 necessary for "wildly successful" protocols that have more disparate
 uses than can reasonably be considered during the design of a
 replacement.  For example, HTTP/2 does not aspire to cause the
 eventual decommissioning of HTTP/1.1 for these reasons.

4. Translation/Adaptation Location

 A translation or adaptation mechanism is often required if the old
 and new mechanisms are not interoperable.  Care must be taken when
 determining whether one will work and where such a translator is best
 placed.
 A translation mechanism may not work for every use case.  For
 example, if translation from one protocol (or protocol version) to
 another produces indeterminate results, translation will not work
 reliably.  In addition, if translation always produces a downgraded
 protocol result, the incentive considerations in Section 5.2 will be
 relevant.
 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 [RFC7754].
 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].
 In addition, when a translator is within an endpoint, it can attempt
 to hide the difference between an older protocol and a newer
 protocol, either by exposing one of the two sets of behavior to
 applications and internally mapping it to the other set of behavior,
 or by exposing a higher level of abstraction that is then
 alternatively mapped to either one depending on detecting which is
 needed.  In contrast, when a translator is in the middle of the path,
 typically only the first approach can be done since the middle of the
 path is typically unable to provide a higher level of abstraction.
 Any transition strategy for a non-backward-compatible mechanism
 should include a discussion of where the incompatible mechanism is
 placed and a rationale.  The transition plan should also consider the
 transition away from the use of translation and adaptation
 technologies.

Thaler Informational [Page 6] RFC 8170 Planning for Transition May 2017

5. Transition Plans

 A review of the case studies described in Appendix A suggests that a
 good transition plan include at least the following components: an
 understanding of what is already deployed and in use, an explanation
 of incentives for each entity involved, a description of the phases
 of the transition along with a proposed criteria for each phase, a
 method for measuring the transition's success, a contingency plan for
 failure of the transition, and an effective method for communicating
 the plan to the entities involved and incorporating their feedback
 thereon.  We recommend that such criteria be considered when
 evaluating proposals to transition to new or updated protocols.  Each
 of these components is discussed in the subsections below.

5.1. Understanding of Existing Deployment

 Often an existing mechanism has variations in implementations and
 operational deployments.  For example, a specification might include
 optional behaviors that may or may not be implemented or deployed.
 In addition, there may also be implementations or deployments that
 deviate from, or include vendor-specific extensions to, various
 aspects of a specification.  It is important when considering a
 transition to understand what variations one is intending to
 transition from or coexist with, since the technical and
 non-technical issues may vary greatly as a result.

5.2. Explanation of Incentives

 A transition plan should explain the incentives to each involved
 entity to support the transition.  Note here that many entities other
 than the endpoint applications and their users may be affected, and
 the barriers to transition may be non-technical as well as technical.
 When considering these incentives, also consider network operations
 tools, practices and processes, personnel training, accounting and
 billing dependencies, and legal and regulatory incentives.
 If there is opposition to a particular new protocol (e.g., from
 another standards organization, or a government, or some other
 affected entity), various non-technical issues arise that should be
 part of what is planned and dealt with.  Similarly, if there are
 significant costs or other disincentives, the plan needs to consider
 how to overcome them.
 It's worth noting that an analysis of incentives can be difficult and
 at times led astray by wishful thinking, as opposed to adequately
 considering economic realities.  Thus, honestly considering any
 barriers to transition, and justifying one's conclusions about
 others' incentives, are key to a successful analysis.

Thaler Informational [Page 7] RFC 8170 Planning for Transition May 2017

5.3. Description of Phases and Proposed Criteria

 Transition phases might include pilot/experimental deployment,
 coexistence, deprecation, and removal phases for a transition from
 one technology to another incompatible one.
 Timelines are notoriously difficult to predict and impossible to
 impose on uncoordinated transitions at the scale of the Internet, but
 rough estimates can sometimes help all involved entities to
 understand the intended duration of each phase.  More often, it is
 useful to provide criteria that must be met in order to move to the
 next phase.  For example, is removal scheduled for a particular date
 (e.g., Federal Communications Commission (FCC) regulation to
 discontinue analog TV broadcasts in the U.S. by June 12, 2009), or is
 removal to be based on the use of the old mechanism falling below a
 specified level, or some other criteria?
 As one example, RFC 5211 [RFC5211] proposed a transition plan for
 IPv6 that included a proposed timeline and criteria specific to each
 phase.  While the timeline was not accurately followed, the phases
 and timeline did serve as inputs to the World IPv6 Day and World IPv6
 Launch events.

5.4. Measurement of Success

 The degree of deployment of a given protocol or feature at a given
 phase in its transition can be measured differently, depending on its
 design.  For example, server-side protocols and options that identify
 themselves through a versioning or negotiation mechanism can be
 discovered through active Internet measurement studies.

5.5. Contingency Planning

 A contingency plan can be as simple as providing for indefinite
 coexistence between an old and new protocol, or for reverting to the
 old protocol until an updated version of the new protocol is
 available.  Such a plan is useful in the event that unforeseen
 problems are discovered during deployment, so that such problems can
 be quickly mitigated.
 For example, World IPv6 Day included a contingency plan that was to
 revert to the original state at the end of the day.  After
 discovering no issues, some participants found that this contingency
 plan was unnecessary and kept the new state.

Thaler Informational [Page 8] RFC 8170 Planning for Transition May 2017

5.6. Communicating the Plan

 Many of the entities involved in a protocol transition may not be
 aware of the IETF or the RFC series, so dissemination through other
 channels is key for sufficiently broad communication of the
 transition plan.  While flag days are impractical at Internet scale,
 coordinated "events" such as World IPv6 Launch may improve general
 awareness of an ongoing transition.
 Also, there is often a need for an entity facilitating the transition
 through advocacy and focus.  Such an entity, independent of the IETF,
 can be key in communicating the plan and its progress.
 Some transitions have a risk of breaking backwards compatibility for
 some fraction of users.  In such a case, when a transition affects
 competing entities facing the risk of losing customers to each other,
 there is an economic disincentive to transition.  Thus, one role for
 a facilitating entity is to get competitors to transition during the
 same timeframe, so as to mitigate this fear.  For example, the
 success of World IPv6 Launch was largely due to ISOC playing this
 role.

6. 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 [RFC7754].
 In addition, coexistence of two protocols in general increases risk
 in the sense that it doubles the attack surface.  It allows
 exploiters to choose the weaker of two protocols when both are
 available, or to force use of the weaker when negotiating between the
 protocols by claiming not to understand the stronger one.

7. IANA Considerations

 This document does not require any IANA actions.

Thaler Informational [Page 9] RFC 8170 Planning for Transition May 2017

8. Conclusion

 This document summarized the set of issues that should be considered
 by protocol designers and deployers to facilitate transition and
 provides pointers to previous work (e.g., [RFC3692] and [RFC6709])
 that provided detailed design guidelines.  This document also covered
 what makes for a good transition plan and includes several case
 studies that provide examples.  As more experience is gained over
 time on how to successfully apply these principles and design
 effective transition plans, we encourage the community to share such
 learnings with the IETF community and on the
 architecture-discuss@ietf.org mailing list so that any future
 document on this topic can leverage such experience.

9. Informative References

 [GREASE]   Benjamin, D., "Applying GREASE to TLS Extensibility", Work
            in Progress, draft-ietf-tls-grease-00, January 2017.
 [HTTP0.9]  Tim Berners-Lee, "The Original HTTP as defined in 1991",
            1991, <https://www.w3.org/Protocols/HTTP/
            AsImplemented.html>.
 [IabIpv6TransitionStatement]
            IAB, "Follow-up work on NAT-PT", October 2007,
            <https://www.iab.org/documents/correspondence-reports-
            documents/docs2007/follow-up-work-on-nat-pt/>.
 [IPv6Survey2011]
            Botterman, M., "IPv6 Deployment Survey", 2011,
            <https://www.nro.net/wp-content/uploads/
            ipv6_deployment_survey.pdf>.
 [IPv6Survey2015]
            British Telecommunications, "IPv6 Industry Survey Report",
            August 2015, <http://www.globalservices.bt.com/static/asse
            ts/pdf/products/diamond_ip/IPv6-Survey-Report-2015.pdf>.
 [PAM2015]  Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I.,
            Fairhurst, G., and R. Scheffenegger, "Enabling Internet-
            Wide Deployment of Explicit Congestion Notification",
            Proceedings of PAM 2015, DOI 10.1007/978-3-319-15509-8_15,
            2015, <http://ecn.ethz.ch/ecn-pam15.pdf>.
 [RFC1883]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
            December 1995, <http://www.rfc-editor.org/info/rfc1883>.

Thaler Informational [Page 10] RFC 8170 Planning for Transition May 2017

 [RFC1933]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
            IPv6 Hosts and Routers", RFC 1933, DOI 10.17487/RFC1933,
            April 1996, <http://www.rfc-editor.org/info/rfc1933>.
 [RFC1945]  Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
            Transfer Protocol -- HTTP/1.0", RFC 1945,
            DOI 10.17487/RFC1945, May 1996,
            <http://www.rfc-editor.org/info/rfc1945>.
 [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
            Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
            RFC 2068, DOI 10.17487/RFC2068, January 1997,
            <http://www.rfc-editor.org/info/rfc2068>.
 [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Frystyk, "Use
            and Interpretation of HTTP Version Numbers", RFC 2145,
            DOI 10.17487/RFC2145, May 1997,
            <http://www.rfc-editor.org/info/rfc2145>.
 [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
            of Explicit Congestion Notification (ECN) to IP",
            RFC 3168, DOI 10.17487/RFC3168, September 2001,
            <http://www.rfc-editor.org/info/rfc3168>.
 [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, <http://www.rfc-editor.org/info/rfc3424>.
 [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
            Considered Useful", BCP 82, RFC 3692,
            DOI 10.17487/RFC3692, January 2004,
            <http://www.rfc-editor.org/info/rfc3692>.
 [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
            Network Address Translations (NATs)", RFC 4380,
            DOI 10.17487/RFC4380, February 2006,
            <http://www.rfc-editor.org/info/rfc4380>.
 [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
            (CIDR): The Internet Address Assignment and Aggregation
            Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
            2006, <http://www.rfc-editor.org/info/rfc4632>.
 [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,
            <http://www.rfc-editor.org/info/rfc4690>.

Thaler Informational [Page 11] RFC 8170 Planning for Transition May 2017

 [RFC5211]  Curran, J., "An Internet Transition Plan", RFC 5211,
            DOI 10.17487/RFC5211, July 2008,
            <http://www.rfc-editor.org/info/rfc5211>.
 [RFC5218]  Thaler, D. and B. Aboba, "What Makes for a Successful
            Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
            <http://www.rfc-editor.org/info/rfc5218>.
 [RFC5894]  Klensin, J., "Internationalized Domain Names for
            Applications (IDNA): Background, Explanation, and
            Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
            <http://www.rfc-editor.org/info/rfc5894>.
 [RFC5895]  Resnick, P. and P. Hoffman, "Mapping Characters for
            Internationalized Domain Names in Applications (IDNA)
            2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
            <http://www.rfc-editor.org/info/rfc5895>.
 [RFC6055]  Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
            Encodings for Internationalized Domain Names", RFC 6055,
            DOI 10.17487/RFC6055, February 2011,
            <http://www.rfc-editor.org/info/rfc6055>.
 [RFC6269]  Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
            P. Roberts, "Issues with IP Address Sharing", RFC 6269,
            DOI 10.17487/RFC6269, June 2011,
            <http://www.rfc-editor.org/info/rfc6269>.
 [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
            RFC 6455, DOI 10.17487/RFC6455, December 2011,
            <http://www.rfc-editor.org/info/rfc6455>.
 [RFC6709]  Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
            Considerations for Protocol Extensions", RFC 6709,
            DOI 10.17487/RFC6709, September 2012,
            <http://www.rfc-editor.org/info/rfc6709>.
 [RFC7021]  Donley, C., Ed., Howard, L., Kuarsingh, V., Berg, J., and
            J. Doshi, "Assessing the Impact of Carrier-Grade NAT on
            Network Applications", RFC 7021, DOI 10.17487/RFC7021,
            September 2013, <http://www.rfc-editor.org/info/rfc7021>.
 [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
            Constrained-Node Networks", RFC 7228,
            DOI 10.17487/RFC7228, May 2014,
            <http://www.rfc-editor.org/info/rfc7228>.

Thaler Informational [Page 12] RFC 8170 Planning for Transition May 2017

 [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
            Protocol (HTTP/1.1): Message Syntax and Routing",
            RFC 7230, DOI 10.17487/RFC7230, June 2014,
            <http://www.rfc-editor.org/info/rfc7230>.
 [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
            "Transport Layer Security (TLS) Application-Layer Protocol
            Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
            July 2014, <http://www.rfc-editor.org/info/rfc7301>.
 [RFC7305]  Lear, E., Ed., "Report from the IAB Workshop on Internet
            Technology Adoption and Transition (ITAT)", RFC 7305,
            DOI 10.17487/RFC7305, July 2014,
            <http://www.rfc-editor.org/info/rfc7305>.
 [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
            Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
            DOI 10.17487/RFC7540, May 2015,
            <http://www.rfc-editor.org/info/rfc7540>.
 [RFC7541]  Peon, R. and H. Ruellan, "HPACK: Header Compression for
            HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
            <http://www.rfc-editor.org/info/rfc7541>.
 [RFC7754]  Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
            Nordmark, "Technical Considerations for Internet Service
            Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
            March 2016, <http://www.rfc-editor.org/info/rfc7754>.
 [TR46]     The Unicode Consortium, "Unicode IDNA Compatibility
            Processing", Version 9.0.0, June 2016,
            <http://www.unicode.org/reports/tr46/>.
 [TSV2007]  Sridharan, M., Bansal, D., and D. Thaler, "Implementation
            Report on Experiences with Various TCP RFCs", Proceedings
            of IETF 68, March 2007, <http://www.ietf.org/proceedings/
            68/slides/tsvarea-3/sld1.htm>.

Thaler Informational [Page 13] RFC 8170 Planning for Transition May 2017

Appendix A. Case Studies

 Appendix A of [RFC5218] describes a number of case studies that are
 relevant to this document and highlight various transition problems
 and strategies (see, for instance, the Inter-Domain Multicast case
 study in Appendix A.4 of [RFC5218]).  We now include several
 additional case studies that focus on transition problems and
 strategies.  Many other equally good case studies could have been
 included, but, in the interests of brevity, only a sampling is
 included here that is sufficient to justify the conclusions in the
 body of this document.

A.1. Explicit Congestion Notification

 Explicit Congestion Notification (ECN) is a mechanism to replace loss
 as the only signal for the detection of congestion.  It does this
 with an explicit signal first sent from a router to a recipient of a
 packet, which is then reflected back to the sender.  It was
 standardized in 2001 in [RFC3168], and the mechanism consists of two
 parts: congestion detection in the IP layer, reusing two bits of the
 old IP Type of Service (TOS) field, and congestion feedback in the
 transport layer.  Feedback in TCP uses two TCP flags, ECN Echo and
 Congestion Window Reduced.  Together with a suitably configured
 active queue management (AQM), ECN can improve TCP performance on
 congested links.
 The deployment of ECN is a case study in failed transition followed
 by possible redemption.  Initial deployment of ECN in the early and
 mid 2000s led to severe problems with some network equipment,
 including home router crashes and reboots when packets with ECN IP or
 TCP flags were received [TSV2007].  This led to firewalls stripping
 ECN IP and TCP flags, or even dropping packets with these flags set.
 This stalled deployment.  The need for both endpoints (to negotiate
 and support ECN) and on-path devices (to mark traffic when congestion
 occurs) to cooperate in order to see any benefits from ECN deployment
 was a further issue.  The deployment of ECN across the Internet had
 failed.
 In the late 2000s, Linux and Windows servers began defaulting to
 "passive ECN support", meaning they would negotiate ECN if asked by
 the client but would not ask to negotiate ECN by default.  This
 decision was regarded as without risk: only if a client was
 explicitly configured to negotiate ECN would any possible
 connectivity problems surface.  Gradually, this has increased server
 support in the Internet from near zero in 2008, to 11% of the top
 million Alexa webservers in 2011, to 30% in 2012, and to 65% in late
 2014.  In the meantime, the risk to connectivity of ECN negotiation
 has reduced dramatically [PAM2015], leading to ongoing work to make

Thaler Informational [Page 14] RFC 8170 Planning for Transition May 2017

 Windows, Apple iOS, OSX, and Linux clients negotiate ECN by default.
 It is hoped that a critical mass of clients and servers negotiating
 ECN will provide an incentive to mark congestion on ECN-enabled
 traffic, thus breaking the logjam.

A.2. Internationalized Domain Names

 The deployment of Internationalized Domain Names (IDNs) has a long
 and complicated history.  This should not be surprising, since
 internationalization deals with language and cultural issues
 regarding differing expectations of users around the world, thus
 making it inherently difficult to agree on common rules.
 Furthermore, because human languages evolve and change over time,
 even if common rules can be established, there is likely to be a need
 to review and update them regularly.
 There have been multiple technical transitions related to IDNs,
 including the introduction of non-ASCII in DNS, the transition to
 each new version of Unicode, and the transition from IDNA 2003 to
 IDNA 2008.  A brief history of the introduction of non-ASCII in DNS
 and the various complications that arose therein, can be found in
 Section 3 of [RFC6055].  While IDNA 2003 was limited to Unicode
 version 3.2 only, one of the IDNA 2008 changes was to decouple its
 rules from any particular version of Unicode (see [RFC5894],
 especially Section 1.4, for more discussion of this point, and see
 [RFC4690] for a list of other issues with IDNA 2003 that motivated
 IDNA 2008).  However, the transition from IDNA 2003 to IDNA 2008
 itself presented a problem since IDNA 2008 did not preserve backwards
 compatibility with IDNA 2003 for a couple of codepoints.
 Investigations and discussions with affected parties led to the IETF
 ultimately choosing IDNA 2008 because the overall gain by moving to
 IDNA 2008 to fix the problems with IDNA 2003 was seen to be much
 greater than the problems due to the few incompatibilities at the
 time of the change, as not many IDNs were in use and even fewer that
 might see incompatibilities.
 A couple of browser vendors in particular were concerned about the
 differences between IDNA 2003 and IDNA 2008, and the fact that if a
 browser stopped being able to get to some site, or unknowingly sent a
 user to a different (e.g., phishing) site instead, the browser would
 be blamed.  As such, any user-perceivable change from IDNA 2003
 behavior would be painful to the vendor to deal with; hence, they
 could not depend on solutions that would need action by other
 entities.

Thaler Informational [Page 15] RFC 8170 Planning for Transition May 2017

 Thus, to deal with issues like such incompatibilities, some
 applications and client-side frameworks wanted to map one string into
 another (namely, a string that would give the same result as when
 IDNA 2003 was used) before invoking DNS.
 To provide such mapping (and some other functionality), the Unicode
 Consortium published [TR46], which continued down the path of IDNA
 2003 with a code point by code point selection mechanism.  This was
 implemented by some, but never adopted by the IETF.
 Meanwhile, the IETF did not publish any mapping mechanism, but
 [RFC5895] was published on the Independent Submission stream.  In
 discussions around mapping, one of the key topics was about how long
 the transition should last.  At one end of the duration spectrum is a
 flag day where some entities would be broken initially but the change
 would happen before IDN usage became even more ubiquitous.  At the
 other end of the spectrum is the need to maintain mappings
 indefinitely.  Local incentives at each entity who needed to change,
 however, meant that a short timeframe was impractical.
 There are many affected types of entities with very different
 incentives.  For example, the incentives affecting browser vendors,
 registries, domain name marketers and applicants, app developers, and
 protocol designers are each quite different, and the various
 solutions require changes by multiple types of entities, where the
 benefits do not always align with the costs.  If there is some group
 (or even an individual) that is opposed to a change/transition and
 able to put significant resources behind their opposition,
 transitions get a lot harder.
 Finally, there are multiple naming contexts, and the protocol
 behavior (including how internationalized domain names are handled)
 within each naming context can be different.  Hence, applications and
 frameworks often encounter a variety of behaviors and may or may not
 be designed to deal with them.  See Sections 2 and 3 of [RFC6055] for
 more discussion.
 In summary, all this diversity can cause problems for each affected
 entity, especially if a competitor does not have such a problem,
 e.g., for browser vendors if competing browsers do not have the same
 problems, or for an email server provider if competing server
 providers do not have the same problems.

Thaler Informational [Page 16] RFC 8170 Planning for Transition May 2017

A.3. IPv6

 Twenty-one years after publication of [RFC1883], the transition to
 IPv6 is still in progress.  The first document to describe a
 transition plan ([RFC1933]) was published less than a year after the
 protocol itself.  It recommended coexistence (dual-stack or tunneling
 technology) with the expectation that over time, all hosts would have
 IPv6, and IPv4 could be quietly retired.
 In the early stages, deployment was limited to peer-to-peer uses
 tunneled over IPv4 networks.  For example, Teredo [RFC4380] aligned
 the cost of fixing the problem with the benefit and allowed for
 incremental benefits to those who used it.
 Operating system vendors had incentives because with such tunneling
 protocols, they could get peer-to-peer apps working without depending
 on any infrastructure changes.  That resulted in the main apps using
 IPv6 being in the peer-to-peer category (BitTorrent, Xbox gaming,
 etc.).
 Router vendors had some incentive because IPv6 could be used within
 an intra-domain network more efficiently than tunneling, once the OS
 vendors already had IPv6 support and some special-purpose apps
 existed.
 For content providers and ISPs, on the other hand, there was little
 incentive for deployment: there was no incremental benefit to
 deploying locally.  Since everyone already had IPv4, there was no
 network effect benefit to deploying IPv6.  Even as proponents argued
 that workarounds to extend the life of IPv4 -- such as Classless
 Inter-Domain Routing (CIDR) [RFC4632] , NAT, and stingy allocations
 -- made it more complex, IPv4 continued to work well enough for most
 applications.
 Workarounds to NAT problems documented in [RFC6269] and [RFC7021]
 included Interactive Connectivity Establishment (ICE), Session
 Traversal Utilities for NAT (STUN), and Traversal Using Relays around
 NAT (TURN), technologies that allowed those experiencing the problems
 to deploy technologies to resolve them.  As with end-to-end IPv6
 tunneling (e.g., Teredo), the incentives there aligned the cost of
 fixing the problem with the benefit and allowed for incremental
 benefits to those who used them.  The IAB discussed NAT technology
 proposals [RFC3424] and recommended that they be considered short-
 term fixes and said that proposals must include an exit plan, such
 that they would decline over time.  In particular, the IAB warned
 against generalizing NAT solutions, which would lead to greater

Thaler Informational [Page 17] RFC 8170 Planning for Transition May 2017

 dependence on them.  In some ways, these solutions, along with other
 IPv4 development (e.g., the workarounds above, and retrofitting IPsec
 into IPv4) continued to reduce the incentive to deploy IPv6.
 Some early advocates overstated the benefits of IPv6, suggesting that
 it had better security (because IPsec was required) or that NAT was
 worse than it often appeared to be or that IPv4 exhaustion would
 happen years sooner than it actually did.  Some people pushed back on
 these exaggerations, and decided that the protocol itself somehow
 lacked credibility.
 Not until a few years after IPv4 addresses were exhausted in various
 RIR regions did IPv6 deployment significantly increase.  The RIRs had
 been advocating in their communities for IPv6 for some time, reducing
 fees for IPv6, and in some cases providing training; there is little
 to suggest that these had a significant effect.  The RIRs and others
 conducted surveys of different industries and industry segments to
 learn why people did not deploy IPv6 [IPv6Survey2011]
 [IPv6Survey2015], which commonly listed lack of a business case, lack
 of training, and lack of vendor support as primary hurdles.
 Arguably forward-looking companies collaborated, with ISOC, on World
 IPv6 Day and World IPv6 Launch to jump-start global IPv6 deployment.
 By including multiple competitors, World IPv6 Day reduced the risk
 that any of them would lose customers if a user's IPv6 implementation
 was broken.  World IPv6 Launch then set a goal for content providers
 to permanently enable IPv6, and for large ISPs to enable IPv6 for at
 least 1% of end users.  These large, visible deployments gave vendors
 specific features and target dates to support IPv6 well.  Key aspects
 of World IPv6 Day and World IPv6 Launch that contributed to their
 successes (measured as increased deployment of IPv6) were the
 communication through ISOC, and that measurement metrics and
 contingency plans were announced in advance.
 Several efforts have been made to mitigate the lack of a business
 case.  Some governments (South Korea and Japan) provided tax
 incentives to include IPv6.  Other governments (Belgium and
 Singapore) mandated IPv6 support by private companies.  Few of these
 had enough value to drive significant IPv6 deployment.
 The concern about lack of training is often a common issue in
 transitions.  Because IPv4 is so ubiquitous, its use is routine and
 simplified with common tools, and it is taught in network training
 everywhere.  While IPv6 deployment was low, ignorance of it was no
 obstacle to being hired as a network administrator or developer.

Thaler Informational [Page 18] RFC 8170 Planning for Transition May 2017

 Organizations with the greatest incentives to deploy IPv6 are those
 that continue to grow quickly, even after IPv4 free-pool exhaustion.
 Thus, ISPs have had varying levels of commitment, based on the growth
 of their user base, services being added (especially video over IP),
 and the number of IPv4 addresses they had available.  Cloud-based
 providers, including Content Delivery Network (CDN) and hosting
 companies, have been major buyers of IPv4 addresses, and several have
 been strong deployers and advocates of IPv6.
 Different organizations will use different transition models for
 their networks, based on their needs.  Some are electing to use
 IPv6-only hosts in the network with IPv6-IPv4 translation at the
 edge.  Others are using dual-stack hosts with IPv6-only routers in
 the core of the network, and IPv4 tunneled or translated through them
 to dual-stack edge routers.  Still others are using native dual-stack
 throughout the network, but that generally persists as an interim
 measure: adoption of two technologies is not the same as
 transitioning from one technology to another.  Finally, some walled
 gardens or isolated networks, such as management networks, use
 IPv6-only end-to-end.
 It is impossible to predict with certainty the path IPv6 deployment
 will have taken when it is complete.  Lessons learned so far include
 aligning costs and benefits (incentive), and ensuring incremental
 benefit (network effect or backward compatibility).

A.4. HTTP

 HTTP has been through several transitions as a protocol.
 The first version [HTTP0.9] was extremely simple, with no headers,
 status codes, or explicit versioning.  HTTP/1.0 [RFC1945] introduced
 these and a number of other concepts; it succeeded mostly because
 deployment of HTTP was still relatively new, with a small pool of
 implementers and (comparatively) small set of deployments and users.
 HTTP/1.1 [RFC7230] (first defined in [RFC2068]) was an attempt to
 make the protocol suitable for the massive scale it was being
 deployed upon and to introduce some new features.
 HTTP/2 [RFC7540] was largely aimed at improving performance.  The
 primary improvement was the introduction of request multiplexing,
 which is supported by request prioritization and flow control.  It
 also introduced header compression [RFC7541] and binary framing; this
 made it completely backwards incompatible on the wire, but still
 semantically compatible with previous versions of the protocol.

Thaler Informational [Page 19] RFC 8170 Planning for Transition May 2017

A.4.1. Protocol Versioning, Extensions, and 'Grease'

 During the development of HTTP/1.1, there was a fair amount of
 confusion regarding the semantics of HTTP version numbers, resulting
 in [RFC2145].  Later, it was felt that minor versioning in the
 protocol caused more confusion than it was worth, so HTTP/2.0 became
 HTTP/2.
 This decision was informed by the observation that many
 implementations ignored the major version number of the protocol or
 misinterpreted it.  As is the case with many protocol extension
 points, HTTP versioning had failed to be "greased" by use often
 enough, and so had become "rusted" so that only a limited range of
 values could interoperate.
 This phenomenon has been observed in other protocols, such as TLS (as
 exemplified by [GREASE]), and there are active efforts to identify
 extension points that are in need of such "grease" and making it
 appear as if they are in use.
 Besides the protocol version, HTTP's extension points that are well-
 greased include header fields, status codes, media types, and cache-
 control extensions; HTTP methods, content-encodings, and chunk-
 extensions enjoy less flexibility, and need to be extended more
 cautiously.

A.4.2. Limits on Changes in Major Versions

 Each update to the "major" version of HTTP has been accompanied by
 changes that weren't compatible with previous versions.  This was not
 uniformly successful given the diversity and scale of deployment and
 implementations.
 HTTP/1.1 introduced pipelining to improve protocol efficiency.
 Although it did enjoy implementation, interoperability did not
 follow.
 This was partially because many existing implementations had chosen
 architectures that did not lend themselves to supporting it;
 pipelining was not uniformly implemented and where it was, support
 was sometimes incorrect or incomplete.  Since support for pipelining
 was indicated by the protocol version number itself, interop was
 difficult to achieve, and furthermore its inability to completely
 address head-of-line blocking issues made pipelining unattractive.
 Likewise, HTTP/1.1's Expect/Continue mechanism relied on wide support
 for the new semantics it introduced and did not have an adequate
 fallback strategy for previous versions of the protocol.  As a

Thaler Informational [Page 20] RFC 8170 Planning for Transition May 2017

 result, interoperability and deployment suffered and is still
 considered a "problem area" for the protocol.
 More recently, the HTTP working group decided that HTTP/2 represented
 an opportunity to improve security, making the protocol much stricter
 than previous versions about the use of TLS.  To this end, a long
 list of TLS cipher suites were prohibited, constraints were placed on
 the key exchange method, and renegotiation was prohibited.
 This did cause deployment problems.  Though most were minor and
 transitory, disabling renegotiation caused problems for deployments
 that relied on the feature to authenticate clients and prompted new
 work to replace the feature.
 A number of other features or characteristics of HTTP were identified
 as potentially undesirable as part of the HTTP/2 process and
 considered for removal.  This included trailers, the 1xx series of
 responses, certain modes of request forms, and the unsecured
 (http://) variant of the protocol.
 For each of these, the risk to the successful deployment of the new
 version was considered to be too great to justify removing the
 feature.  However, deployment of the unsecured variant of HTTP/2
 remains extremely limited.

A.4.3. Planning for Replacement

 HTTP/1.1 provided the Upgrade header field to enable transitioning a
 connection to an entirely different protocol.  So far, this has been
 little-used, other than to enable the use of WebSockets [RFC6455].
 With performance being a primary motivation for HTTP/2, a new
 mechanism was needed to avoid spending an additional round trip on
 protocol negotiation.  A new mechanism was added to TLS to permit the
 negotiation of the new version of HTTP: Application-Layer Protocol
 Negotiation (ALPN) [RFC7301].  Upgrade was used only for the
 unsecured variant of the protocol.
 ALPN was identified as the primary way in which future protocol
 versions would be negotiated.  The mechanism was well-tested during
 development of the specification, proving that new versions could be
 deployed safely and easily.  Several draft versions of the protocol
 were successfully deployed during development, and version
 negotiation was never shown to be an issue.
 Confidence that new versions would be easy to deploy if necessary
 lead to a particular design stance that might be considered unusual
 in light of the advice in [RFC5218], though is completely consistent

Thaler Informational [Page 21] RFC 8170 Planning for Transition May 2017

 with [RFC6709]: few extension points were added, unless an immediate
 need was understood.
 This decision was made on the basis that it would be easier to revise
 the entire protocol than it would be to ensure that an extension
 point was correctly specified and implemented such that it would be
 available when needed.

IAB Members at the Time of Approval

 Jari Arkko
 Ralph Droms
 Ted Hardie
 Joe Hildebrand
 Russ Housley
 Lee Howard
 Erik Nordmark
 Robert Sparks
 Andrew Sullivan
 Dave Thaler
 Martin Thomson
 Brian Trammell
 Suzanne Woolf

Acknowledgements

 This document is a product of the IAB Stack Evolution Program, with
 input from many others.  In particular, Mark Nottingham, Dave
 Crocker, Eliot Lear, Joe Touch, Cameron Byrne, John Klensin, Patrik
 Faltstrom, the IETF Applications Area WG, and others provided helpful
 input on this document.

Author's Address

 Dave Thaler (editor)
 One Microsoft Way
 Redmond, WA  98052
 United States of America
 Email: dthaler@microsoft.com

Thaler Informational [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8170.txt · Last modified: 2017/05/17 19:32 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki