[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-thaler-transition-principles) 00 01 02 03 04 05 06 07 08 RFC 8170

Internet Architecture Board                               D. Thaler, Ed.
Internet-Draft                                                 Microsoft
Intended status: Informational                            March 21, 2016
Expires: September 22, 2016

Out With the Old and In With the New: Planning for Protocol Transitions


   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 September 22, 2016.

Copyright Notice

   Copyright (c) 2016 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 September 22, 2016               [Page 1]

Internet-Draft           Planning for Transition              March 2016

   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.  IAB Members at the Time of This Writing . . . . . . . . . . .   5
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Case Studies . . . . . . . . . . . . . . . . . . . .   7
     A.1.  Explicit Congestion Notification  . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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 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

   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 WG to address this

Thaler                 Expires September 22, 2016               [Page 2]

Internet-Draft           Planning for Transition              March 2016

   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.

   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 September 22, 2016               [Page 3]

Internet-Draft           Planning for Transition              March 2016

   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
       (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.

Thaler                 Expires September 22, 2016               [Page 4]

Internet-Draft           Planning for Transition              March 2016

   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].

   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.  IAB Members at the Time of This Writing

Thaler                 Expires September 22, 2016               [Page 5]

Internet-Draft           Planning for Transition              March 2016

   Jari Arkko
   Mary Barnes
   Marc Blanchet
   Ralph Droms
   Ted Hardie
   Joe Hildebrand
   Russ Housley
   Erik Nordmark
   Robert Sparks
   Andrew Sullivan
   Dave Thaler
   Brian Trammell
   Suzanne Woolf

8.  Informative References

              Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
              Nordmark, "Technical Considerations for Internet Service
              Blocking and Filtering", draft-iab-filtering-
              considerations-09 (work in progress), November 2015.

              IAB, "Follow-up work on NAT-PT", October 2007,

   [PAM2015]  Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I.,
              Fairhurst, G., and R. Scheffenegger, "Enabling Internet-
              Wide Deployment of Explicit Congestion Notification",
              2015, <target: http://ecn.ethz.ch/ecn-pam15.pdf>.

   [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,

   [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>.

   [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,

Thaler                 Expires September 22, 2016               [Page 6]

Internet-Draft           Planning for Transition              March 2016

   [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,

   [TSV2007]  Sridharan, M., Bansal, D., and D. Thaler, "Implementation
              Report on Experiences with Various TCP RFCs", March 2007,

Appendix A.  Case Studies

A.1.  Explicit Congestion Notification

   Explicit Congestion Notification (ECN) is a mechanism to replace loss
   as the only signal for the detection of congestion with an explicit
   signal sent from a router to the recipient of a packet, then
   reflected back to the sender.  It was standardized in 2000 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.

Thaler                 Expires September 22, 2016               [Page 7]

Internet-Draft           Planning for Transition              March 2016

   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 was 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 had failed.

   In the late 2000s, Linux and Windows servers defaulted 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 were 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, 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 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.

Author's Address

   Dave Thaler (editor)
   One Microsoft Way
   Redmond, WA  98052

   Email: dthaler@microsoft.com

Thaler                 Expires September 22, 2016               [Page 8]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/