[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                 Best Current Practice
INTERNET-DRAFT                                          Scott O. Bradner
<draft-iesg-vendor-extensions-02.txt>                 Harvard University
                                                           Thomas Narten
                                                            June 4, 2004

           Considerations on the Extensibility of IETF protocols


Status of this Memo
   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   This document discusses issues related to the extensibility of IETF
   protocols, including when it is reasonable to extend IETF protocols
   with little or no review, and when extensions need to be reviewed by
   the larger IETF community. Experience with IETF protocols has shown
   that extensibility of protocols without IETF review can cause
   problems. The document also recommends that major extensions to IETF

draft-iesg-vendor-extensions-02.txt                             [Page 1]

INTERNET-DRAFT                                              June 4, 2004

   protocols only take place through normal IETF processes or in
   coordination with the IETF.


   Status of this Memo..........................................    1

   1.  Introduction.............................................    2

   2.  Interoperability.........................................    3

   3.  Extensibility............................................    4
      3.1.  Minor Extensions....................................    5
      3.2.  Major Extensions....................................    6
      3.3.  Classification of Major vs. Minor Extensions........    6

   4.  Review of Proposed Protocol Extensions...................    7

   5.  Recommendation...........................................    7

   6.  Summary..................................................    8

   7.  Examples.................................................    8
      7.1.  RADIUS Extensions...................................    9
      7.2.  RSVP Extensions.....................................   10
      7.3.  L2TP Extensions.....................................   10

   8.  IANA Considerations......................................   11

   9.  Security Considerations..................................   11

   10.  Acknowledgments.........................................   11

   11.  Informative References..................................   11

   12.  Editor's Addresses......................................   11

1.  Introduction

   When developing protocols, IETF working groups typically include
   mechanisms whereby these protocols can be extended in the future.
   Vendors, standards development organizations and technology fora have
   used those facilities.  Sometimes the result is a poorly designed
   mechanism and non-interoperability.

   It is of course a good principle to design extensiblity into
   protocols; one common definition of a successful protocol is one that

draft-iesg-vendor-extensions-02.txt                             [Page 2]

INTERNET-DRAFT                                              June 4, 2004

   becomes widely used in ways not originally anticipated. Well-designed
   extensibility mechanisms facilitate the evolution of protocols and
   help make it easier to roll-out incremental changes in an
   interoperable fashion. At the same time, experience has shown that
   extensibility features should be limited to what is clearly necessary
   when the protocol is developed and any later extensions should be
   done carefully and with a full understanding of the base protocol,
   existing implementations, and current operational practice.

   If extensions to IETF protocols are done outside the IETF, experience
   has shown that documentation of these extensions can be hard to
   obtain, short-sighted design choices are sometimes made, basic
   underlying architectural principals of the protocol are sometimes
   violated, assessing the quality of the specification is hard and
   achieving interoperability can be hard.

   This memo makes explicit some guiding principles based on the
   community's experience with extensibility mechanisms. One of the key
   principles is that protocols should not be made more extensible than
   clearly necessary at inception, and that proposed extensions should
   be reviewed by subject-matter experts familiar with the protocol
   itself and how it is used in currently deployed systems. The IESG is
   presently applying some version of these principles in evaluating
   proposals for new extensions and in evaluating the extensibility of
   new protocols.

2.  Interoperability

   The importance of extending protocols only in carefully thought-out
   ways is driven by the overall goal of acheiving good
   interoperability. Good interoperability stems from a number of
   factors, including:

      - having a well-written spec, that makes clear and precise what an
        implementor needs to implement and what impact each individual
        operation (e.g., a message sent to a peer) will have when
        invoked. However, while necessary, a well-written spec is not by
        itself sufficient to result in good interoperability.

      - learning lessons from deployment, including understanding what
        current implementations do and how a proposed extension will
        interact with deployed systems.

      - having an adequate transition story for deploying the new
        extension. What impact will the proposed extension have on
        implementations that do not understand it? Is there a way to
        negotiate or determine the capabilities of a peer?

draft-iesg-vendor-extensions-02.txt                             [Page 3]

INTERNET-DRAFT                                              June 4, 2004

      - being archtitecturally compatable with the base protocol.  For
        example, does the extension make use of features as envisioned
        by the original protocol designers, or is a new mechanism being

      - respecting underlying architectural or security assumptions
        (including those that may not be well-documented, those that may
        have arison as a result of operational experience, or those that
        only became understood after the original protocol was

      - will the proposed extension (or its proposed usage)
        operationally stress existing implementations or the underlying
        protocol itself if widely deployed?

      - some protocols have become critical components of the Internet
        infrastructure. Does the proposed extension (or its proposed
        usage) have the potential for negatively impacting such
        infrastructure to the point where explicit steps would be
        appropriate to firewall existing uses from new ones?

      - does the proposed extension extend the data model in a major
        way?  Does the extension fundamentally change basic assumptions
        about data handling within the protocol?  For example, do the
        extensions reverse the flow of data, allow formerly static
        parameters to be changed on the fly, add new data types or
        change assumptions relating to the frequency of reads/writes?

   In practice, the only way to ensure that a proposed extension makes
   sense and will result in good interoperability is to have the
   extension reviewed by subject-matter experts familiar with the

   Ideally, the document that defines a base protocol's extension
   mechanisms will include guidance to future extension writers that
   help them use extension mechanisms properly. It may also be possible
   to define classes of extensions that need little or no review, while
   other classes need wide review. The specific details will necessarily
   be technology-specific.

3.  Extensibility

   The best defense against poorly thought-out extensions is review by
   subject matter experts.  Such experts can identify potential problems
   early and suggest alternative approaches with fewer problems. To
   improve interoperability, such review must take place before
   significant deployment of an extension takes place. Once an extension

draft-iesg-vendor-extensions-02.txt                             [Page 4]

INTERNET-DRAFT                                              June 4, 2004

   is deployed and in use, it becomes difficult or impossible to
   deprecate the extension or otherwise recall implementations.

   Protocols that permit easy extensions with minimal or no review, make
   it likely that unreviewed extensions will be deployed and used in
   practice. Consequently, protocols should not be made more extensible
   than clearly necessary at inception, and the process for defining new
   extensibility mechanisms must ensure that adequate review of proposed
   extensions will take place before widespread adoption. In practice,
   this means First Come First Served [IANA-CONSID] and similar policies
   should be used very carefully, as they imply minimal or no review.

3.1.  Minor Extensions

   The amount and type of review necessary for a proposed extension can
   vary considerably. For example, many protocols are designed to carry
   opaque data, without examining or acting on the data at all. For
   example, DHCP [DHC] transports options, but the contents of an
   individual option is generally of no concern to the DHCP protocol
   itself. Many other protocols provide such a capability, including
   OSPF LSAs, BGP, Radius Attributes, Diameter AVPs, etc. A new
   extension may be nothing more than having an existing protocol carry
   a different kind of opaque data. In such cases, minimal review may be
   adequate.. For the purposes of this document, we call such extensions
   "Minor Extensions".  Important points to note about Minor Extensions

      o The protocol is designed to carry such opaque data and no
        changes to the underlying base protocol are needed to carry a
        new type of data.  Moreover, no changes are required to existing
        and currently deployed implementations of the underlying
        protocol unless they want to make use of the new data type.

      o Using the existing protocol to carry a new type of opaque data
        will not impact existing implementations or cause operational

   Examples of minor extensions include the DHC vendor-specific option,
   the enterprise OID tree for MIB modules, vnd. MIME types, and some
   classes of (non-critical) certification extensions. Such extensions
   can safely be made with minimal IETF coordination and are indicated
   by having an IANA Considerations that allows assignments of code
   points with minimal overhead (e.g., First Come First Served) [IANA-

   In order to increase the likelyhood that minor extensions are truly
   minor, protocol documents should provide guidelines explaining how

draft-iesg-vendor-extensions-02.txt                             [Page 5]

INTERNET-DRAFT                                              June 4, 2004

   they should be done. For example, even though DHCP carries opaque
   data, defining a new option using completely unstructured data may
   lead to an option that is (unnecessarily) hard for clients and
   servers to process. In contrast, using widely-supported encoding
   formats leads to better interoperability [XXX need ref]. Similarly,
   SNMP MIB guidelines exist for defining the MIB objects that SNMP
   carries [MIB-GUIDELINES].

3.2.  Major Extensions

   Some extensions change the protocol itself (e.g, the bits-on-the-
   wire), change the interpretation of previously defined Protocol Data
   Units (PDUs), or require protocol-specific changes in the client,
   server, or other intermediate nodes. Such changes can be both subtle
   and significant, and generally warrant careful review. Examples here
   would include new protocol message types. For the purposes of this
   document, we call such extensions Major Extensions.

   Major extensions have some or all of the following characteristics:

      o Change or extend the way in which the basic underlying protocol
        works, e.g., by changing the semantics of existing PDUs or
        defining new message types that require implementation changes
        in existing and deployed implementations of the protocols, even
        if they do not want to make use of the new functions or data

      o Change basic architectural assumptions about the protocol that
        have been an assumed part of the protocol and its

      o Lead to new uses of the protocol in ways not originally intended
        or investigated, potentially leading to operational and other
        difficulties when deployed, even in cases where the "on-the-
        wire" format has not changed. For example, the overall quantity
        of traffic the protocol is expected to carry might go up
        substantially, typical packet sizes may increase compared to
        existing deployments, simple implementation algorithms that are
        widely deployed may not scale sufficiently or otherwise be up to
        the new task at hand, etc.

3.3.  Classification of Major vs. Minor Extensions

   Exactly what is considered to be a major extension and what is
   considered normal usage will depend on the specific protocol and the
   proposed extension at issue. Even for protocols designed to carry

draft-iesg-vendor-extensions-02.txt                             [Page 6]

INTERNET-DRAFT                                              June 4, 2004

   opaque data, whether a proposed usage qualifies as a major extension
   may involve considerable debate. For example, RADIUS is designed to
   carry AVPs and allow definition of new AVPs.  But it is important
   that such discussion involve the IETF community of experts
   knowledgeable about the protocol's architecture and existing usage in
   order to fully understand the implications of a proposed extension.

4.  Review of Proposed Protocol Extensions

   Major extensions to IETF protocols should be well, and publicly,
   documented and reviewed by the IETF community to be sure that the
   extension does not undermine basic assumptions and safeguards
   designed into the protocol, such as security functions, or undermine
   its architectural integrity.

5.  Recommendation

   The following principles are the main guiding principles concerning
   extensions to IETF protocols:

      o Extensibility features in IETF protocols should be limited to
        providing just the amount of extensibility that is seen as
        required.  Protocols should not be extensible just for the sake
        of being extensible.

      o All major extensions to IETF protocols should be done with
        adequate review by or direct involvement of the IETF.

      o The decision on whether an extension is major or minor should be
        done with the direct involvement of the IETF.

      o Protocols should include IANA considerations section that ensure
        that protocol code point assignments that are needed to deploy
        extensions are not made until after a proposed extension has
        received adequate review.

   Ideally, extensions should be done by IETF working groups using
   normal IETF processes or, if a working group does not consider a
   proposed extension to be general enough, at least documented in an
   IETF informational RFC that is reviewed by the working group and the
   IESG.  No individual, vendor, standards development organization or
   forum should be able create what is viewed to be a major extension to
   an IETF protocol on its own and be able to claim (or create the
   appearance) that the extensions are part of the IETF protocol.

   It should also be noted that the second bullet above leads to the
   possibility of a denial-of-service issue, as it implies that any

draft-iesg-vendor-extensions-02.txt                             [Page 7]

INTERNET-DRAFT                                              June 4, 2004

   major extension must be done within or reviewed by the IETF, and that
   the IETF is required to take on all such work. In practice, the IETF
   may not have the resources to develop (or even review) every possible
   extension and will need to prioritize the use of its resources. Thus,
   it is important to be pragmatic in terms of what work can and will be
   taken on by the IETF, and to set expectations accordingly. In those
   cases where the IETF is unable to take on a particular work item, it
   should be understood that the IETF will review extensions to its
   technology that it is asked to publish, and may approve publication
   only after changes are made, or may not agree to publish the
   extension at all. Thus, anyone proposing extensions outside of the
   IETF is advised to coordinate any such extensions with the IETF as
   early as possible. Waiting until the last minute before consulting
   with the IETF and then assuming quick publication of a finished
   extension is not recommended.

   It should also be noted that there are limits to what the IETF can do
   to prevent others from improperly extending protocols outside of the
   IETF. The IETF's leverage is limited to such actions as recommending
   against publication of an extension or denying the assignment of an
   IANA code point (e.g., when relevant IANA considerations guidelines
   apply). There is also the real possibility that the development of a
   poor extension will generate ill-will in the IETF community, which
   can greatly complicate subsequent attempts by the offending group to
   carry out future work in the IETF, whether directly related to the
   particular extension or not.

6.  Summary

   IETF protocols should not be designed to encourage the definition of
   major extensions outside the IETF process.  Documents defining IETF
   protocols should carefully analyze and identify which protocol
   components can be extended safely with minimal or no community review
   and which need community review, and then write appropriate IANA
   considerations sections that ensure the appropriate level of
   community review prior to the assignment of numbers. For example, the
   definition of additional data formats that can be carried may require
   no review, while the addition of new protocol message types might
   require a Standards Track action [IANA-CONSID].

7.  Examples

   This section discusses some specific examples, as it is not always
   immediately clear what constitutes a major extension.

   [note: to be completed, are the following good and representative of

draft-iesg-vendor-extensions-02.txt                             [Page 8]

INTERNET-DRAFT                                              June 4, 2004

   some of the debates that have been had?]

7.1.  RADIUS Extensions

   The RADIUS [RFC2865] protocol was designed to be extensible via
   addition of Attributes to a Data Dictionary on the server, without
   requiring code changes.  However, this extensibility model assumed
   that Attributes would conform to a limited set of data types and that
   vendor extensionns would be limited to use by vendors in situations
   in which interoperability was not required.  Recent developments have
   stretched those assumptions.

   [RFC2865] Section 6.2 defines a mechanism for Vendor-Specific
   extensions (Attribute 26), and states that use:

   "... should be encouraged instead of allocation of global attribute
   types, for functions specific only to one vendor's implementation of
   RADIUS, where no interoperability is deemed useful."

However, in practice usage of Vendor-Specific Attributes (VSAs) has been
considerably broader than this;  in particular, VSAs have been used by
SDOs to define their extensions to the RADIUS protocol.

This has caused a number of problems.  Since the VSA mechanism was not
designed for interoperability, VSAs  do not contain a "mandatory" bit.
As a  result, RADIUS clients  and servers may  not know whether  it is
safe to  ignore unknown attributes.  For example,  [RFC2865] Section 5

   "A RADIUS server MAY ignore Attributes with an unknown Type.  A
   RADIUS client MAY ignore Attributes with an unknown Type."

However, in the case where the VSAs pertain to security (e.g.  Filters)
it may not be safe to ignore them, since [RFC2865] also states:

   "A NAS that does not implement a given service MUST NOT implement the
   RADIUS attributes for that service.  For example, a NAS that is
   unable to offer ARAP service MUST NOT implement the RADIUS attributes
   for ARAP.  A NAS MUST treat a RADIUS access-accept authorizing an
   unavailable service as an access-reject instead."

   Since it was not envisaged that multi-vendor VSA implementations
   would need to interoperate, [RFC2865] does not define the data model
   for VSAs, and allows multiple subattributes to be included within a
   single Attribute of type 26.  However, this enables VSAs to be
   defined which would not be supportable by current implementations if
   placed within the standard RADIUS attribute space.  This has caused

draft-iesg-vendor-extensions-02.txt                             [Page 9]

INTERNET-DRAFT                                              June 4, 2004

   problems in standardizing widely deployed VSAs.

   In addition to extending RADIUS by use of VSAs, SDOs have also
   defined new values of the Service-Type attribute in order to create
   new RADIUS commands.  Since [RFC2865] defined Service-Type values as
   being allocated First Come, First Served (FCFS), this essentially
   enabled new RADIUS commands to be allocated without IETF review.
   This oversight has since been fixed in [RFC3575].

7.2.  RSVP Extensions

7.3.  L2TP Extensions

   L2TP [L2TP] carries Attribute-Value Pairs (AVPs), with most AVPs
   having no semantics to the L2TP protocol itself. However, it should
   be noted that L2TP message types are identified by a Message Type AVP
   (Attribute Type 0) with specific AVP values indicating the actual
   message type. Thus, extensions relating to Message Type AVPs would
   likely be considered major extensions.

   L2TP also provides for Vendor-Specific AVPs. Because everything in
   L2TP is encoded using AVPs, it would be easy to define vendor-
   specific AVPs that would be considered major extensions.

   L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP
   messages containing AVPs they do not understand but that have the
   mandatory bit set, are expected to reject the message and terminate
   the tunnel or session the message refers to. This leads to
   interesting interoperability issues, because a sender can include a
   vendor-specific AVP with the M-bit set, which then cause the
   recipient to not interoperate with the sender. This sort of behavior
   is counter to the IETF ideals, as implementations of the IETF
   standard should interoperate successfully with other implementations
   and not require the implementation of non-IETF extensions in order to
   interoperate successfully. Section 4.2 of the L2TP specification
   [L2TP] includes specific wording on this point, though there was
   significant debate at the time as to whether such language was by
   itself sufficient.

   Fortunately, it does not appear that the above concerns have been a
   problem in practice. At the time of this writing, the authors are
   unaware of the existance of vendor-specific AVPs that also set the M-

draft-iesg-vendor-extensions-02.txt                            [Page 10]

INTERNET-DRAFT                                              June 4, 2004

8.  IANA Considerations


9.  Security Considerations

   Insufficiently reviewed extensions can easily lead to protocols with
   significant security vulnerabilities.  In addition, a poorly designed
   extension can circumvent strong security features that the IETF
   designed into a protocol.

10.  Acknowledgments

   The initial version of this document was put together by the IESG in
   2002. Since then, it has been reworked in response to feedback from
   John Loughney, Henrik Levkowetz, Mark Townsley, Randy Bush, Bernard
   Aboba and others.

11.  Informative References

   [IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing
           an IANA Considerations Section in RFCs", BCP 26, RFC 2434,
           October 1998.

   [L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
           and B. Peter, "Layer Two Tunneling Protocol (L2TP)", RFC
           2661, August 1999.
   [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
           March 1997.

   [MIB-GUIDELINES] draft-ietf-ops-mib-review-guidelines-02.txt

   [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial
           In User Service). B. Aboba. July 2003.

   [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
           Authentication Dial In User Service (RADIUS)", RFC 2865, June

12.  Editor's Addresses

   Scott Bradner
   Harvard University
   29 Oxford St

draft-iesg-vendor-extensions-02.txt                            [Page 11]

INTERNET-DRAFT                                              June 4, 2004

   Cambridge MA 02138

   Phone: +1 617-495-3864
   EMail: sob@harvard.edu

   Thomas Narten
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709-2195

   Phone: +1 919 254 7798
   EMail: narten@us.ibm.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

Disclaimer of Validity

   This document and the information contained herein are provided on an

draft-iesg-vendor-extensions-02.txt                            [Page 12]

INTERNET-DRAFT                                              June 4, 2004


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

draft-iesg-vendor-extensions-02.txt                            [Page 13]