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

Versions: 00 01 02                                                      
INTERNET-DRAFT                                          Scott O. Bradner
<draft-iesg-vendor-extensions-01.txt>                 Harvard University
                                                           Thomas Narten
                                                        October 27, 2003

           Considerations on the Extensibility of IETF protocols


Status of this Memo
   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   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


   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. The document also recommends that major
   extensions to IETF protocols only take place through normal IETF
   processes or in coordination with the IETF.


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

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

   2.  Principles...............................................    2

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

INTERNET-DRAFT                                          October 27, 2003

   3.  Recommendation...........................................    4

   4.  Examples.................................................    6
      4.1.  RADIUS Vendor-Specific Attributes...................    6
      4.2.  LDAP Schema Extensions..............................    6
      4.3.  L2TP Extensions.....................................    6

   5.  IANA Considerations......................................    7

   6.  Security Considerations..................................    7

   7.  Acknowledgments..........................................    7

   8.  Informative References...................................    7

   9.  Editor's Addresses.......................................    7

1.  Introduction

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

   The purpose of this memo is to make 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.  The IESG is
   presently applying some version of these principles when evaluating
   proposals for new standards.

2.  Principles

   The most important principle driving this memo, and in fact the IETF
   as a whole is the principle of:

      o IETF Standards are intended to encourage and enable multiple
        implementers to build implementations of protocols that will

   It is a good principle to design extensible protocols but
   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.

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

INTERNET-DRAFT                                          October 27, 2003

   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.

   It can be particularly difficult for a user to figure out who is at
   fault and what to do about it if two pieces of software that both
   claim to be implementations of an IETF standard do not work together.

   Yet there are situations where extensions to IETF protocols can make
   sense. There are two general ways in which protocols are extended.
   Many (if not most) protocols are designed to carry opaque data of
   some kind, where the protocol itself mostly doesn't care what the
   contents of that data is. For example, DHCP [DHC] transports options,
   but the contents of the option are 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.
   Important points to note about such extensions include:

      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.  Specifically, no changes are required to
        existing and currently deployed implementations 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-

   The more interesting way in which protocols are extended is called a
   major extension. Major extensions have some or all of the following

      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

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

INTERNET-DRAFT                                          October 27, 2003


      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.

   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
   opaque data, whether a proposed usage qualifies as a major extension
   may involve considerable debate. 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.

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

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

   Ideally, extensions should be done by IETF working groups using

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

INTERNET-DRAFT                                          October 27, 2003

   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 legitimately be able to claim that
   implementations that implement the extension are compliant to the
   IETF specification, or that the extension is a part of the IETF

   It should be noted that the second bullet above leads to the
   possibility of a denial-of-service issue, as it implies that any
   major extension should be done within or reviewed by the IETF. At the
   same time, 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.

   IETF protocols should not be designed to encourage the definition of
   major extensions outside the IETF process.  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].

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

INTERNET-DRAFT                                          October 27, 2003

4.  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 some of the debates that have been had?]

4.1.  RADIUS Vendor-Specific Attributes

4.2.  LDAP Schema Extensions

4.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-01.txt                             [Page 6]

INTERNET-DRAFT                                          October 27, 2003

5.  IANA Considerations


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

7.  Acknowledgments

   The initial version of this document was put together by the IESG.

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

9.  Editor's Addresses

   Scott Bradner
   Harvard University
   29 Oxford St
   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

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

INTERNET-DRAFT                                          October 27, 2003

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

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