Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6709

Design Considerations for Protocol Extensions

Pages: 42
Informational
Part 1 of 2 – Pages 1 to 18
None   None   Next

Top   ToC   RFC6709 - Page 1
Internet Architecture Board (IAB)                           B. Carpenter
Request for Comments: 6709                                 B. Aboba, Ed.
Category: Informational                                      S. Cheshire
ISSN: 2070-1721                                           September 2012


             Design Considerations for Protocol Extensions

Abstract

This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. 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 5741. 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/rfc6709. Copyright Notice Copyright (c) 2012 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.
Top   ToC   RFC6709 - Page 2

Table of Contents

1. Introduction ....................................................3 1.1. Requirements Language ......................................4 2. Routine and Major Extensions ....................................4 2.1. What Constitutes a Major Extension? ........................4 2.2. When is an Extension Routine? ..............................6 3. Architectural Principles ........................................7 3.1. Limited Extensibility ......................................7 3.2. Design for Global Interoperability .........................8 3.3. Architectural Compatibility ...............................12 3.4. Protocol Variations .......................................13 3.5. Testability ...............................................16 3.6. Protocol Parameter Registration ...........................16 3.7. Extensions to Critical Protocols ..........................17 4. Considerations for the Base Protocol ...........................18 4.1. Version Numbers ...........................................19 4.2. Reserved Fields ...........................................22 4.3. Encoding Formats ..........................................23 4.4. Parameter Space Design ....................................23 4.5. Cryptographic Agility .....................................26 4.6. Transport .................................................27 4.7. Handling of Unknown Extensions ............................28 5. Security Considerations ........................................29 6. References .....................................................30 6.1. Normative References ......................................30 6.2. Informative References ....................................30 7. Acknowledgments ................................................35 8. IAB Members at the Time of Approval ............................35 Appendix A. Examples .............................................36 A.1. Already-Documented Cases ..................................36 A.2. RADIUS Extensions .........................................36 A.3. TLS Extensions ............................................39 A.4. L2TP Extensions ...........................................41
Top   ToC   RFC6709 - Page 3

1. Introduction

When developing protocols, IETF Working Groups (WGs) often include mechanisms whereby these protocols can be extended in the future. It is often a good principle to design extensibility into protocols; as described in "What Makes for a Successful Protocol" [RFC5218], a "wildly successful" protocol is one that 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. However, at the same time, experience has shown that extensions carry the risk of unintended consequences, such as interoperability issues, operational problems, or security vulnerabilities. The proliferation of extensions, even well-designed ones, can be costly. As noted in "Simple Mail Transfer Protocol" [RFC5321] Section 2.2.1: Experience with many protocols has shown that protocols with few options tend towards ubiquity, whereas protocols with many options tend towards obscurity. Each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs. This is hardly a recent concern. "TCP Extensions Considered Harmful" [RFC1263] was published in 1991. "Extend" or "extension" occurs in the title of more than 400 existing Request for Comments (RFC) documents. Yet, generic extension considerations have not been documented previously. The purpose of this document is to describe the architectural principles of sound extensibility design, in order to minimize such risks. Formal procedures for extending IETF protocols are discussed in "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775]. The rest of this document is organized as follows: Section 2 discusses routine and major extensions. Section 3 describes architectural principles for protocol extensibility. Section 4 explains how designers of base protocols can take steps to anticipate and facilitate the creation of such subsequent extensions in a safe and reliable manner. Section 5 discusses security considerations. Appendix A provides case studies. Readers are advised to study the whole document, since the considerations are closely linked.
Top   ToC   RFC6709 - Page 4

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" BCP 14 [RFC2119].

2. Routine and Major Extensions

The risk of unintended consequences from an extension is especially high if the extension is performed by a different team than the original designers, who may stray outside implicit design constraints or assumptions. As a result, it is highly desirable for the original designers to articulate the design constraints and assumptions, so as to enable extensions to be done carefully and with a full understanding of the base protocol, existing implementations, and current operational practice. To assist extension designers and reviewers, protocol documents should provide guidelines explaining how extensions should be performed, and guidance on how protocol extension mechanisms should be used. Protocol components that are designed with the specific intention of allowing extensibility should be clearly identified, with specific and complete instructions on how to extend them. This includes the process for adequate review of extension proposals: do they need community review, and if so, how much and by whom? The level of review required for protocol extensions will typically vary based on the nature of the extension. Routine extensions may require minimal review, while major extensions may require wide review. Guidance on which extensions may be considered 'routine' and which ones are 'major' is provided in the sections that follow.

2.1. What Constitutes a Major Extension?

Major extensions may have characteristics leading to a risk of interoperability failures, security vulnerabilities, or operational problems. Where these characteristics are present, it is necessary to pay close attention to backward compatibility with implementations and deployments of the unextended protocol and to the potential for inadvertent introduction of security or operational exposures.
Top   ToC   RFC6709 - Page 5
   Extension designers should examine their design for the following
   issues:

   1.  Modifications or extensions to the underlying protocol.  An
       extension document should be considered to update the underlying
       protocol specification if an implementation of the underlying
       protocol would need to be updated to accommodate the extension.
       This should not be necessary if the underlying protocol was
       designed with a modular interface.  Examples of extensions
       modifying the underlying protocol include specification of
       additional transports (see Section 4.6), changing protocol
       semantics, or defining new message types that may require
       implementation changes in existing and deployed implementations
       of the protocol, even if they do not want to make use of the new
       functions.  A base protocol that does not uniformly permit
       "silent discard" of unknown extensions may automatically enter
       this category, even for apparently minor extensions.  Handling of
       "unknown" extensions is discussed in more detail in Section 4.7.

   2.  Changes to the basic architectural assumptions.  This may include
       architectural assumptions that are explicitly stated or those
       that have been assumed by implementers.  For example, this would
       include adding a requirement for session state to a previously
       stateless protocol.

   3.  New usage scenarios not originally intended or investigated.
       This can potentially lead to operational difficulties when
       deployed, even in cases where the "on-the-wire" format has not
       changed.  For example, the level of traffic carried by the
       protocol may increase substantially, packet sizes may increase,
       and implementation algorithms that are widely deployed may not
       scale sufficiently or otherwise be up to the new task at hand.
       For example, a new DNS Resource Record (RR) type that is too big
       to fit into a single UDP packet could cause interoperability
       problems with existing DNS clients and servers.  Similarly, the
       additional traffic that results from an extension to a routing
       protocol could have a detrimental impact on the performance or
       stability of implementations that do not implement the extension.

   4.  Changes to the extension model.  Adverse impacts are very likely
       if the base protocol contains an extension mechanism and the
       proposed extension does not fit into the model used to create and
       define that mechanism.  Extensions that have the same properties
       as those that were anticipated when an extension mechanism was
       devised are much less likely to be disruptive than extensions
       that don't fit the model.  Also, changes to the extension model
       itself (including changes limiting further extensibility) can
       create interoperability problems.
Top   ToC   RFC6709 - Page 6
   5.  Changes to protocol syntax.  Changes to protocol syntax bring
       with them the potential for backward-compatibility issues.  If at
       all possible, extensions should be designed for compatibility
       with existing syntax, so as to avoid interoperability failures.

   6.  Interrelated extensions to multiple protocols.  A set of
       interrelated extensions to multiple protocols typically carries a
       greater danger of interoperability issues or incompatibilities
       than a simple extension.  Consequently, it is important that such
       proposals receive earlier and more in-depth review than unitary
       extensions.

   7.  Changes to the security model.  Changes to the protocol security
       model (or even addition of new security mechanisms within an
       existing framework) can introduce security vulnerabilities or
       adversely impact operations.  Consequently, it is important that
       such proposals undergo security as well as operational review.
       Security considerations are discussed in Section 5.

   8.  Performance impact.  An extension that impacts performance can
       have adverse consequences, particularly if the performance of
       existing deployments is affected.

2.2. When is an Extension Routine?

An extension may be considered 'routine' if it does not meet the criteria for being considered a 'major' extension and if its handling is opaque to the protocol itself (e.g., does not substantially change the pattern of messages and responses). For this to apply, no changes to the base protocol can be required, nor can changes be required to existing and currently deployed implementations, unless they make use of the extension. Furthermore, existing implementations should not be impacted. This typically requires that implementations be able to ignore 'routine' extensions without ill effects. Examples of routine extensions include the Dynamic Host Configuration Protocol (DHCP) vendor-specific option [RFC2132], Remote Authentication Dial In User Service (RADIUS) Vendor-Specific Attributes [RFC2865], the enterprise Object IDentifier (OID) tree for Management Information Base (MIB) modules, and vendor Multipurpose Internet Mail Extension (MIME) types. Such extensions can safely be made with minimal discussion.
Top   ToC   RFC6709 - Page 7
   Processes that allow routine extensions with minimal or no review
   (such as "First Come First Served" (FCFS) allocation [RFC5226])
   should be used sparingly.  In particular, they should be limited to
   cases that are unlikely to result in interoperability problems or in
   security or operational exposures.

   Experience has shown that even routine extensions may benefit from
   review by experts.  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.

3. Architectural Principles

This section describes basic principles of protocol extensibility: 1. Extensibility features should be limited to what is reasonably anticipated when the protocol is developed. 2. Protocol extensions should be designed for global interoperability. 3. Protocol extensions should be architecturally compatible with the base protocol. 4. Protocol extension mechanisms should not be used to create incompatible protocol variations. 5. Extension mechanisms need to be testable. 6. Protocol parameter assignments need to be coordinated to avoid potential conflicts. 7. Extensions to critical components require special care. A critical component is one whose failure can lead to Internet-wide reliability and security issues or performance degradation.

3.1. Limited Extensibility

Protocols should not be made more extensible than clearly necessary at inception, in order to enable optimization along dimensions (e.g., bandwidth, state, memory requirements, deployment time, latency, etc.) important to the most common use cases. The process for defining new extensibility mechanisms should ensure that adequate review of proposed extensions will take place before widespread adoption.
Top   ToC   RFC6709 - Page 8
   As noted in "What Makes for a Successful Protocol" [RFC5218], "wildly
   successful" protocols far exceed their original goals, in terms of
   scale, purpose (being used in scenarios far beyond the initial
   design), or both.  This implies that all potential uses may not be
   known at inception.  As a result, extensibility mechanisms may need
   to be revisited as additional use cases reveal themselves.  However,
   this does not imply that an initial design needs to take all
   potential needs into account at inception.

3.2. Design for Global Interoperability

Section 3.1 of "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775] notes: According to its Mission Statement [RFC3935], the IETF produces high quality, relevant technical and engineering documents, including protocol standards. The mission statement goes on to say that the benefit of these standards to the Internet "is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users". One consequence of this mission is that the IETF designs protocols for the single Internet. The IETF expects its protocols to work the same everywhere. Protocol extensions designed for limited environments may be reasonable provided that products with these extensions interoperate with products without the extensions. Extensions that break interoperability are unacceptable when products with and without the extension are mixed. It is the IETF's experience that this tends to happen on the Internet even when the original designers of the extension did not expect this to happen. Another consequence of this definition of interoperability is that the IETF values the ability to exchange one product implementing a protocol with another. The IETF often specifies mandatory-to- implement functionality as part of its protocols so that there is a core set of functionality sufficient for interoperability that all products implement. The IETF tries to avoid situations where protocols need to be profiled to specify which optional features are required for a given environment, because doing so harms interoperability on the Internet as a whole. Since the global Internet is more than a collection of incompatible protocols (or "profiles") for use in separate private networks, implementers supporting extensions in shipping products or multi-site experimental usage must assume that systems will need to interoperate on the global Internet.
Top   ToC   RFC6709 - Page 9
   A key requirement for interoperable extension design is that the base
   protocol must be well designed for interoperability and that
   extensions must have unambiguous semantics.  Ideally, the protocol
   mechanisms for extension and versioning should be sufficiently well
   described that compatibility can be assessed on paper.  Otherwise,
   when two "private" or "experimental" extensions encounter each other
   on a public network, unexpected interoperability problems may occur.
   However, as noted in the Transport Layer Security (TLS) case study
   (Appendix A.3), it is not sufficient to design extensibility
   carefully; it also must be implemented carefully.

3.2.1. Private Extensions

Experience shows that separate private networks often end up having portable equipment like laptop computers move between them, and networks that were originally envisaged as being separate can end up being connected later. Consider a "private" extension installed on a work computer that, being portable, is sometimes connected to networks other than the work network, like a home network or a hotel network. If the "private" extension is incompatible with an unextended version of the same protocol, problems will occur. Similarly, problems can occur if "private" extensions conflict with each other. For example, imagine the situation where one site chose to use DHCP [RFC2132] option code 62 for one meaning and a different site chose to use DHCP option code 62 for a completely different, incompatible, meaning. It may be impossible for a vendor of portable computing devices to make a device that works correctly in both environments. One approach to solving this problem has been to reserve parts of an identifier namespace for "limited applicability" or "site-specific" use, such as "X-" headers in email messages [RFC822] or "P-" headers in SIP [RFC3427]. However, as noted in "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols" [RFC6648], Appendix B: The primary problem with the "X-" convention is that unstandardized parameters have a tendency to leak into the protected space of standardized parameters, thus introducing the need for migration from the "X-" name to a standardized name. Migration, in turn, introduces interoperability issues (and sometimes security issues) because older implementations will support only the "X-" name and newer implementations might support only the standardized name. To preserve interoperability, newer implementations simply support the "X-" name forever, which means
Top   ToC   RFC6709 - Page 10
      that the unstandardized name has become a de facto standard (thus
      obviating the need for segregation of the name space into
      standardized and unstandardized areas in the first place).

   As a result, the notion of "X-" headers from the 1982 Internet
   Message Format standard [RFC822] was removed when the specification
   was updated in 2001 [RFC2822].  Within SIP, the guidance published in
   2002 regarding "P-" headers [RFC3427] was deprecated eight years
   later in Section 4 of the 2010 update [RFC5727].  More generally, as
   noted in Section 1 of the "X-" prefix deprecation document [RFC6648]:

      This document generalizes from the experience of the email and SIP
      communities by doing the following:

      1.  Deprecates the "X-" convention for newly defined parameters in
          application protocols, including new parameters for
          established protocols.  This change applies even where the
          "X-" convention was only implicit, and not explicitly
          provided, such as was done for email in [RFC822].

3.2.2. Local Use

Values designated as "experimental" or "local use" are only appropriate in limited circumstances such as in early implementations of an extension restricted to a single site. For example, "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers" [RFC4727] discusses experimental values for IP and transport headers, and "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] defines experimental/local use ranges for differentiated services code points. Such values should be used with care and only for their stated purpose: experiments and local use. They are unsuitable for Internet-wide use, since they may be used for conflicting purposes and thereby cause interoperability failures. Packets containing experimental or local use values must not be allowed out of the domain in which they are meaningful. Section 1 of "Assigning Experimental and Testing Numbers Considered Useful" BCP 82 [RFC3692] provides guidance on the use of experimental code points: Numbers in the experimentation range ... are not intended to be used in general deployments or be enabled by default in products or other general releases. In those cases where a product or release makes use of an experimental number, the end user must be
Top   ToC   RFC6709 - Page 11
      required to explicitly enable the experimental feature and
      likewise have the ability to chose and assign which number from
      the experimental range will be used for a specific purpose (i.e.,
      so the end user can ensure that use of a particular number doesn't
      conflict with other on-going uses).  Shipping a product with a
      specific value pre-enabled would be inappropriate and can lead to
      interoperability problems when the chosen value collides with a
      different usage, as it someday surely will.

      From the above, it follows that it would be inappropriate for a
      group of vendors, a consortia, or another Standards Development
      Organization to agree among themselves to use a particular value
      for a specific purpose and then agree to deploy devices using
      those values.  By definition, experimental numbers are not
      guaranteed to be unique in any environment other than one where
      the local system administrator has chosen to use a particular
      number for a particular purpose and can ensure that a particular
      value is not already in use for some other purpose.

      Once an extension has been tested and shown to be useful, a
      permanent number could be obtained through the normal assignment
      procedures.

   However, as noted in Appendix B of the "X-" prefix deprecation
   document [RFC6648], assigning a parameter block for experimental use
   is only necessary when the parameter pool is limited:

      "Assigning Experimental and Testing Numbers Considered Useful" ...
      implies that the "X-" prefix is also useful for experimental
      parameters.  However, BCP 82 addresses the need for protocol
      numbers when the pool of such numbers is strictly limited (e.g.,
      DHCP options) or when a number is absolutely required even for
      purely experimental purposes (e.g., the Protocol field of the IP
      header).  In almost all application protocols that make use of
      protocol parameters (including email headers, media types, HTTP
      headers, vCard parameters and properties, URNs, and LDAP field
      names), the name space is not limited or constrained in any way,
      so there is no need to assign a block of names for private use or
      experimental purposes....

      Therefore, it appears that segregating the parameter space into a
      standardized area and a unstandardized area has few, if any,
      benefits and has at least one significant cost in terms of
      interoperability.
Top   ToC   RFC6709 - Page 12

3.2.3. Multi-Site Experiments

Where an experiment is undertaken among a diverse set of experimental sites connected via the global Internet, the use of "experimental" or "local use" code points is inadvisable. This might include, for example, sites that take a prototype implementation of some protocol and use that both within their site but, importantly, among the full set of other sites interested in that protocol. In such a situation, it is impractical and probably impossible to coordinate the de-confliction of "experimental" code points. Section 4.1 of the IANA Considerations guidelines document [RFC5226] notes: For private or local use ... No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways.... assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). The Host Identity Protocol (HIP) [RFC5201] and the Locator/ID Separation Protocol [LISP] are examples where a set of experimental sites are collaborating among themselves, but not necessarily in a tightly coordinated way. Both HIP and LISP have dealt with this by having unique non-experimental code points allocated to HIP and LISP, respectively, at the time of publication of their respective Experimental RFCs.

3.3. Architectural Compatibility

Since protocol extension mechanisms may impact interoperability, it is important that they be architecturally compatible with the base protocol. This includes understanding what current implementations do and how a proposed extension will interact with deployed systems. Is it clear when a proposed extension (or its proposed usage), if widely deployed, will operationally stress existing implementations or the underlying protocol itself? If this is not explained in the base protocol specification, is this covered in an extension design guidelines document? As part of the definition of a new extension, it is important to address whether the extension makes use of features as envisaged by the original protocol designers, or whether a new extension mechanism is being invented. If a new extension mechanism is being invented, then architectural compatibility issues need to be addressed.
Top   ToC   RFC6709 - Page 13
   To assist in the assessment of architectural compatibility, protocol
   documents should provide guidelines explaining how extensions should
   be performed, and guidance on how protocol extension mechanisms
   should be used.

   Protocol components that are designed with the specific intention of
   allowing extensibility should be clearly identified, with specific
   and complete instructions on how to extend them.  This includes the
   process for adequate review of extension proposals: do they need
   community review, and if so, how much and by whom?

   Documents relying on extension mechanisms need to explicitly identify
   the mechanisms being relied upon.  For example, a document defining
   new data elements should not implicitly define new data types or
   protocol operations without explicitly describing those dependencies
   and discussing their impact.  Where extension guidelines are
   available, mechanisms need to indicate whether they are compliant
   with those guidelines and offer an explanation if they are not.

   Examples of documents describing extension guidelines include:

   1.  "Guidelines for Extending the Extensible Provisioning Protocol
       (EPP)" [RFC3735], which provides guidelines for use of EPP's
       extension mechanisms to define new features and object management
       capabilities.

   2.  "Guidelines for Authors and Reviewers of MIB Documents" BCP 111
       [RFC4181], which provides guidance to protocol designers creating
       new MIB modules.

   3.  "Guidelines for Authors of Extensions to the Session Initiation
       Protocol (SIP)" [RFC4485], which outlines guidelines for authors
       of SIP extensions.

   4.  "Considerations for Lightweight Directory Access Protocol (LDAP)
       Extensions" BCP 118 [RFC4521], which discusses considerations for
       designers of LDAP extensions.

   5.  "RADIUS Design Guidelines" BCP 158 [RFC6158], which provides
       guidelines for the design of attributes used by the Remote
       Authentication Dial In User Service (RADIUS) protocol.

3.4. Protocol Variations

Protocol variations -- specifications that look very similar to the original but don't interoperate with each other or with the original -- are even more harmful to interoperability than extensions. In
Top   ToC   RFC6709 - Page 14
   general, such variations should be avoided.  Causes of protocol
   variations include incompatible protocol extensions, uncoordinated
   protocol development, and poorly designed "profiles".

   Designing a protocol for extensibility may have the perverse side
   effect of making it easy to construct incompatible variations.
   Protocol extension mechanisms should not be used to create
   incompatible forks in development.  An extension may lead to
   interoperability failures unless the extended protocol correctly
   supports all mandatory and optional features of the unextended base
   protocol, and implementations of the base protocol operate correctly
   in the presence of the extensions.  In addition, it is necessary for
   an extension to interoperate with other extensions.

   As noted in Section 1 of "Uncoordinated Protocol Development
   Considered Harmful" [RFC5704], incompatible forks in development can
   result from the uncoordinated adaptation of a protocol, parameter, or
   code point:

      In particular, the IAB considers it an essential principle of the
      protocol development process that only one SDO maintains design
      authority for a given protocol, with that SDO having ultimate
      authority over the allocation of protocol parameter code-points
      and over defining the intended semantics, interpretation, and
      actions associated with those code-points.

   Note that problems can occur even when one Standards Development
   Organization (SDO) maintains design authority, if protocol parameter
   code points are reused.  As an example, EAP-FAST [RFC5421][RFC5422]
   reused previously assigned Extensible Authentication Protocol (EAP)
   type codes.  As described in the IESG note in the EAP-FAST document
   [RFC5421]:

      The reuse of previously assigned EAP Type Codes is incompatible
      with EAP method negotiation as defined in RFC 3748.

3.4.1. Profiles

Profiling is a common technique for improving interoperability within a target environment or set of scenarios. Generally speaking, there are two approaches to profiling: a) Removal or downgrading of normative requirements (thereby creating potential interoperability problems). b) Elevation of normative requirement levels (such as from a MAY/SHOULD to a MUST). This can be done in order to improve interoperability by narrowing potential implementation choices
Top   ToC   RFC6709 - Page 15
       (such as when the underlying protocol is ill-defined enough to
       permit non-interoperable yet compliant implementations) or to
       meet specific operational requirements (such as enabling use of
       stronger cryptographic mechanisms than those mandated in the
       specification).

   While approach a) is potentially harmful, approach b) may be
   beneficial.

   In order to avoid interoperability problems when profiled
   implementations interact with others over the global Internet,
   profilers need to remain cognizant of the implications of removing
   normative requirements.  As noted in Section 6 of "Key words for use
   in RFCs to Indicate Requirement Levels" [RFC2119], imperatives are to
   be used with care, and as a result, their removal within a profile is
   likely to result in serious consequences:

      Imperatives of the type defined in this memo must be used with
      care and sparingly.  In particular, they MUST only be used where
      it is actually required for interoperation or to limit behavior
      which has potential for causing harm (e.g., limiting
      retransmissions)  For example, they must not be used to try to
      impose a particular method on implementors where the method is not
      required for interoperability.

   As noted in Sections 3 and 4 of the Key Words document [RFC2119],
   recommendations cannot be removed from profiles without serious
   consideration:

      [T]here may exist valid reasons in particular circumstances to
      ignore a particular item, but the full implications must be
      understood and carefully weighed before choosing a different
      course.

   Even the removal of optional features and requirements can have
   consequences.  As noted in Section 5 of the Key Words document
   [RFC2119], implementations that do not support optional features
   still retain the obligation to ensure interoperation with
   implementations that do:

      An implementation which does not include a particular option MUST
      be prepared to interoperate with another implementation which does
      include the option, though perhaps with reduced functionality.  In
      the same vein an implementation which does include a particular
      option MUST be prepared to interoperate with another
      implementation which does not include the option (except, of
      course, for the feature the option provides.)
Top   ToC   RFC6709 - Page 16

3.5. Testability

Experience has shown that it is insufficient merely to specify extensibility and backward compatibility correctly in an RFC. It is also important that implementations respect the compatibility mechanisms; if not, non-interoperable pairs of implementations may arise. The TLS case study (Appendix A.3) shows how important this can be. In order to determine whether protocol extension mechanisms have been properly implemented, testing is required. However, for this to be possible, test cases need to be developed. If a base protocol document specifies extension mechanisms but does not utilize them or provide examples, it may not be possible to develop effective test cases based on the base protocol specification alone. As a result, base protocol implementations may not be properly tested, and non- compliant extension behavior may not be detected until these implementations are widely deployed. To encourage correct implementation of extension mechanisms, base protocol specifications should clearly articulate the expected behavior of extension mechanisms and should include examples of correct extension behavior.

3.6. Protocol Parameter Registration

As noted in Section 3.2 of "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775]: An extension is often likely to make use of additional values added to an existing IANA registry.... It is essential that such new values are properly registered by the applicable procedures, including expert review where applicable.... Extensions may even need to create new IANA registries in some cases. Experience shows that the importance of this is often underestimated during extension design; designers sometimes assume that a new codepoint is theirs for the asking, or even simply for the taking. Before creating a new protocol parameter registry, existing registries should be examined to determine whether one of them can be used instead (see http://www.iana.org/protocols/). To avoid conflicting usage of the same registry value, as well as to prevent potential difficulties in determining and transferring parameter ownership, it is essential that all new values are
Top   ToC   RFC6709 - Page 17
   registered.  If this is not done, there is nothing to prevent two
   different extensions picking the same value.  When these two
   extensions "meet" each other on the Internet, failure is inevitable.

   A surprisingly common case of this is misappropriation of assigned
   Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP))
   registered port numbers.  This can lead to a client for one service
   attempting to communicate with a server for another service.  Another
   common case is the use of unregistered URI schemes.  Numerous cases
   could be cited, but not without embarrassing specific implementers.
   For general rules, see the IANA Considerations guidelines document
   [RFC5226], and for specific rules and registries, see the individual
   protocol specification RFCs and the IANA web site.

   While in theory a "Standards Track" or "IETF Consensus" parameter
   allocation policy may be instituted to encourage protocol parameter
   registration or to improve interoperability, in practice, problems
   can arise if the procedures result in so much delay that requesters
   give up and "self-allocate" by picking presumably unused code points.
   Where self-allocation is prevalent, the information contained within
   registries may become inaccurate, particularly when third parties are
   prohibited from updating entries so as to improve accuracy.  In these
   situations, it is important to consider whether registration
   processes need to be changed to support the role of a registry as
   "documentation of how the Internet is operating".

3.7. Extensions to Critical Protocols

Some protocols (such as the Domain Name System (DNS), the Border Gateway Protocol (BGP), and the Hypertext Transfer Protocol (HTTP)) or algorithms (such as congestion control) have become critical components of the Internet infrastructure. A critical component is one whose failure can lead to Internet-wide reliability and security issues or performance degradation. When such protocols or algorithms are extended, the potential exists for negatively impacting the reliability and security of the global Internet. As a result, special care needs to be taken with these extensions, such as taking explicit steps to isolate existing uses from new ones. For example, this can be accomplished by requiring the extension to utilize a different port or multicast address or by implementing the extension within a separate process, without access to the data and control structures of the base protocol. Experience has shown that even when a mechanism has proven benign in other uses, unforeseen issues may result when adding it to a critical protocol. For example, both IS-IS and OSPF support opaque Link State Advertisements (LSAs), which are propagated by intermediate nodes
Top   ToC   RFC6709 - Page 18
   that don't understand the LSA.  Within Interior Gateway Protocols
   (IGPs), support for opaque LSAs has proven useful without introducing
   instability.

   However, within BGP, "attribute tunneling" has resulted in large-
   scale routing instabilities, since remote nodes may reset the LOCAL
   session if the tunneled attributes are malformed or aren't
   understood.  This has required modification to BGP error handling, as
   noted in "Revised Error Handling for BGP UPDATE Messages"
   [ERROR-HANDLING].

   In general, when extending protocols with local failure conditions,
   tunneling of attributes that may trigger failures in non-adjacent
   nodes should be avoided.  This is particularly problematic when the
   originating node receives no indicators of remote failures it may
   have triggered.



(page 18 continued on part 2)

Next Section