idnits 2.17.1 draft-iab-extension-recs-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 445 has weird spacing: '...es used by th...' == Line 753 has weird spacing: '...mber to decla...' == Line 754 has weird spacing: '...message to b...' == Line 755 has weird spacing: '... allows mail ...' == Line 757 has weird spacing: '...hich is presu...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (13 February 2012) is 4457 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1341 (Obsoleted by RFC 1521) -- Obsolete informational reference (is this intentional?): RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board B. Carpenter 3 Internet-Draft B. Aboba (ed) 4 Intended Status: Informational S. Cheshire 5 Expires: August 15, 2012 6 13 February 2012 8 Design Considerations for Protocol Extensions 9 draft-iab-extension-recs-10 11 Abstract 13 This document discusses issues related to the extensibility of 14 Internet protocols, with a focus on architectural design 15 considerations. It is intended to assist designers of both base 16 protocols and extensions. Case studies are included. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 15, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1 Requirements Language . . . . . . . . . . . . . . . . . . 5 72 2. Routine and Major Extensions . . . . . . . . . . . . . . . . . 5 73 2.1 When is an Extension Routine? . . . . . . . . . . . . . . 5 74 2.2 What Constitutes a Major Extension? . . . . . . . . . . . 6 75 3. Architectural Principles . . . . . . . . . . . . . . . . . . . 7 76 3.1 Limited Extensibility . . . . . . . . . . . . . . . . . . 8 77 3.2 Design for Global Interoperability . . . . . . . . . . . . 8 78 3.3 Architectural Compatibility . . . . . . . . . . . . . . . 10 79 3.4 Protocol Variations . . . . . . . . . . . . . . . . . . . 11 80 3.5 Testability . . . . . . . . . . . . . . . . . . . . . . . 12 81 3.6 Parameter Parameter Registration . . . . . . . . . . . . . 13 82 3.7 Extensions to Critical Protocols . . . . . . . . . . . . . 15 83 4. Considerations for the Base Protocol . . . . . . . . . . . . . 16 84 4.1 Version Numbers . . . . . . . . . . . . . . . . . . . . . 17 85 4.2 Reserved Fields . . . . . . . . . . . . . . . . . . . . . 20 86 4.3 Encoding Formats . . . . . . . . . . . . . . . . . . . . . 20 87 4.4 Parameter Space Design . . . . . . . . . . . . . . . . . . 21 88 4.5 Cryptographic Agility . . . . . . . . . . . . . . . . . . 23 89 4.6 Transport . . . . . . . . . . . . . . . . . . . . . . . . 24 90 4.7 Handling of Unknown Extensions . . . . . . . . . . . . . . 25 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 7.1 Normative References . . . . . . . . . . . . . . . . . . . 27 95 7.2 Informative References . . . . . . . . . . . . . . . . . . 27 96 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 97 IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 98 Appendix A - Examples . . . . . . . . . . . . . . . . . . . . . . 32 99 A.1 Already documented cases . . . . . . . . . . . . . . . . . 32 100 A.2 RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 32 101 A.3 TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 33 102 A.4 L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 35 103 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 105 1. Introduction 107 When developing protocols, IETF Working Groups (WGs) often include 108 mechanisms whereby these protocols can be extended in the future. It 109 is a good principle to design extensibility into protocols; as 110 described in "What Makes for a Successful Protocol" [RFC5218], a 111 "wildly successful" protocol is one that becomes widely used in ways 112 not originally anticipated. Well-designed extensibility mechanisms 113 facilitate the evolution of protocols and help make it easier to roll 114 out incremental changes in an interoperable fashion. 116 When an initial protocol design is extended, there is always a risk 117 of unintended consequences, such as interoperability problems or 118 security vulnerabilities. This risk is especially high if the 119 extension is performed by a different team than the original 120 designers, who may stray outside implicit design constraints or 121 assumptions. As a result, it is highly desirable for the original 122 designers to articulate the design constraints and assumptions, so as 123 to enable extensions to be done carefully and with a full 124 understanding of the base protocol, existing implementations, and 125 current operational practice. As noted in the TLS case study (see 126 Appendix A.3), it is not sufficient to design extensibility 127 carefully; it also must be implemented carefully. 129 The proliferation of extensions, even well designed ones, can be 130 costly. As noted in "Simple Mail Transfer Protocol" [RFC5321] 131 Section 2.2.1: 133 Experience with many protocols has shown that protocols with few 134 options tend towards ubiquity, whereas protocols with many options 135 tend towards obscurity. 137 Each and every extension, regardless of its benefits, must be 138 carefully scrutinized with respect to its implementation, 139 deployment, and interoperability costs. 141 This is hardly a recent concern. "TCP Extensions Considered Harmful" 142 [RFC1263] was published in 1991. "Extend" or "extension" occurs in 143 the title of more than 400 existing Request For Comment (RFC) 144 documents. Yet generic extension considerations have not been 145 documented previously. 147 The purpose of this document is to describe the architectural 148 principles of sound extensibility design, in order to minimize such 149 risks. Formal procedures for extending IETF protocols are discussed 150 in "Procedures for Protocol Extensions and Variations" BCP 125 151 [RFC4775]. 153 The rest of this document is organized as follows: Section 2 154 discusses routine and major extensions. Section 3 describes 155 architectural principles for protocol extensibility. Section 4 156 explains how designers of base protocols can take steps to anticipate 157 and facilitate the creation of such subsequent extensions in a safe 158 and reliable manner. 160 Readers are advised to study the whole document, since the 161 considerations are closely linked. 163 1.1. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in BCP 14, RFC 2119 168 [RFC2119]. 170 2. Routine and Major Extensions 172 To assist extension designers and reviewers, protocol documents 173 should provide guidelines explaining how extensions should be 174 performed, and guidance on the appropriate use of protocol extension 175 mechanisms should be developed. 177 Protocol components that are designed with the specific intention of 178 allowing extensibility should be clearly identified, with specific 179 and complete instructions on how to extend them. This includes the 180 process for adequate review of extension proposals: do they need 181 community review and if so how much and by whom? 183 The level of review required for protocol extensions will typically 184 vary based on the nature of the extension. Routine extensions may 185 require minimal review, while major extensions may require wide 186 review. Guidance on which extensions may be considered 'routine' and 187 which ones are 'major' are provided in the sections that follow. 189 2.1. When is an Extension Routine? 191 An extension may be considered 'routine' if its handling is opaque to 192 the protocol itself (e.g. does not substantially change the pattern 193 of messages and responses). For this to apply, no changes to the 194 base protocol can be required, nor can changes be required to 195 existing and currently deployed implementations, unless they make use 196 of the extension. Furthermore, existing implementations should not 197 be impacted. This typically requires that implementations be able to 198 ignore 'routine' extensions without ill-effects. 200 Examples of routine extensions include the Dynamic Host Configuration 201 Protocol (DHCP) vendor-specific option [RFC2132], Remote 202 Authentication Dial In User Service (RADIUS) Vendor-Specific 203 Attributes [RFC2865], the enterprise Object IDentifier (OID) tree for 204 Management Information Base (MIB) modules, vendor Multipurpose 205 Internet Mail Extension (MIME) types, and some classes of (non- 206 critical) certification extensions. Such extensions can safely be 207 made with minimal discussion. 209 Processes that allow routine extensions with minimal or no review 210 should be used sparingly (such as the "First Come First Served" 211 (FCFS) allocation policy described in "Guidelines for Writing an IANA 212 Considerations Section in RFCs" [RFC5226]). In particular, they 213 should be limited to cases that are unlikely to result in 214 interoperability problems, or security or operational exposures. 216 Experience has shown that even routine extensions may benefit from 217 review by experts. For example, even though DHCP carries opaque 218 data, defining a new option using completely unstructured data may 219 lead to an option that is unnecessarily hard for clients and servers 220 to process. 222 2.2. What Constitutes a Major Extension? 224 Major extensions may have characteristics leading to a risk of 225 interoperability failure. Where these characteristics are present, 226 it is necessary to pay close attention to backward compatibility with 227 implementations and deployments of the unextended protocol, and to 228 the risk of inadvertent introduction of security or operational 229 exposures. 231 Extension designers should examine their design for the following 232 issues: 234 1. Modifications or extensions to the underlying protocol. This 235 can include specification of additional transports (see Section 236 4.6), changing protocol semantics or defining new message types 237 that may require implementation changes in existing and deployed 238 implementations of the protocol, even if they do not want to make 239 use of the new functions. A base protocol that does not uniformly 240 permit "silent discard" of unknown extensions may automatically 241 enter this category, even for apparently minor extensions. 242 Handling of "unknown" extensions is discussed in more detail in 243 Section 4.7. 245 2. Changes to the basic architectural assumptions. This may 246 include architectural assumptions that are explicitly stated or 247 those that have been assumed by implementers. For example, this 248 would include adding a requirement for session state to a 249 previously stateless protocol. 251 3. New usage scenarios not originally intended or investigated. 252 This can potentially lead to operational difficulties when 253 deployed, even in cases where the "on-the-wire" format has not 254 changed. For example, the level of traffic carried by the 255 protocol may increase substantially, packet sizes may increase, 256 and implementation algorithms that are widely deployed may not 257 scale sufficiently or otherwise be up to the new task at hand. 258 For example, a new DNS Resource Record (RR) type that is too big 259 to fit into a single UDP packet could cause interoperability 260 problems with existing DNS clients and servers. 262 4. Changes to the extension model. Adverse impacts are very 263 likely if the base protocol contains an extension mechanism and 264 the proposed extension does not fit into the model used to create 265 and define that mechanism. Extensions that have the same 266 properties as those that were anticipated when an extension 267 mechanism was devised are much less likely to be disruptive than 268 extensions that don't fit the model. 270 5. Changes to protocol syntax. Changes to protocol syntax bring 271 with them the potential for backward compatibility issues. If at 272 all possible, extensions should be designed for compatibility with 273 existing syntax, so as to avoid interoperability failures. 275 3. Architectural Principles 277 This section describes basic principles of protocol extensibility: 279 1. Extensibility features should be limited to what is reasonably 280 anticipated when the protocol is developed. 282 2. Protocol extensions should be designed for global 283 interoperability. 285 3. Protocol extensions should be architecturally compatible with 286 the base protocol. 288 4. Protocol extension mechanisms should not be used to create 289 incompatible protocol variations. 291 5. Extension mechanisms need to be testable. 293 6. Protocol parameter assignments need to be coordinated to avoid 294 potential conflicts. 296 7. Extensions to critical protocols require special care. 298 3.1. Limited Extensibility 300 Designing a protocol for extensibility may have the perverse side 301 effect of making it easy to construct incompatible extensions. 302 Consequently, protocols should not be made more extensible than 303 clearly necessary at inception, and the process for defining new 304 extensibility mechanisms should ensure that adequate review of 305 proposed extensions will take place before widespread adoption. 307 As noted in "What Makes for a Successful Protocol" [RFC5218], "wildly 308 successful" protocols far exceed their original goals, in terms of 309 scale, purpose (being used in scenarios far beyond the initial 310 design), or both. This implies that all potential uses may not be 311 known at inception. As a result, extensibility mechanisms may need 312 to be revisited as additional use cases reveal themselves. However, 313 this does not imply that an initial design needs to take all 314 potential needs into account at inception. 316 3.2. Design for Global Interoperability 318 The IETF mission [RFC3935] is to create interoperable protocols for 319 the global Internet, not a collection of different incompatible 320 protocols (or "profiles") for use in separate private networks. 321 Experience shows that separate private networks often end up using 322 equipment from the same vendors, or end up having portable equipment 323 like laptop computers move between them, and networks that were 324 originally envisaged as being separate can end up being connected 325 later. 327 As a result, extensions cannot be designed for an isolated 328 environment; instead, extension designers must assume that systems 329 using the extension will need to interoperate with systems on the 330 global Internet. 332 A key requirement for interoperable extension design is that the base 333 protocol must be well designed for interoperability, and that 334 extensions must have unambiguous semantics. Ideally, the protocol 335 mechanisms for extension and versioning should be sufficiently well 336 described that compatibility can be assessed on paper. Otherwise, 337 when two "private" extensions encounter each other on a public 338 network, unexpected interoperability problems may occur. 340 Consider a "private" extension installed on a work computer which, 341 being portable, is sometimes connected to a home network or a hotel 342 network. If the "private" extension is incompatible with an 343 unextended version of the same protocol, problems will occur. 345 Similarly, problems can occur if "private" extensions conflict with 346 each other. For example, imagine the situation where one site chose 347 to use DHCP [RFC2132] option code 62 for one meaning, and a different 348 site chose to use DHCP option code 62 for a completely different, 349 incompatible, meaning. It may be impossible for a vendor of portable 350 computing devices to make a device that works correctly in both 351 environments. 353 One approach to solving this problem has been to reserve parts of an 354 identifier namespace for "limited applicability" or "site-specific" 355 use, such as "X-" headers in email messages [RFC0822], or "P-" 356 headers in SIP [RFC3427]. This problem with this approach is that 357 when a "limited applicability" or "site-specific" use turns out to 358 have applicability elsewhere, other vendors will then implement that 359 "X-"/"P-" header for interoperability, and the "X-"/"P-" header 360 becomes a de-facto standard, meaning that it is no longer true that 361 any header beginning "X-"/"P-" is "limited applicability" or "site- 362 specific". 364 As a result, the notion of "X-" headers was removed from the Internet 365 Message Format standard when it was updated in 2001 [RFC2822]. 366 Similarly, within SIP, [RFC5727] Section 4 deprecated the guidance 367 provided in [RFC3427] on the creation of "P-" headers: 369 In keeping with the IETF tradition of "running code and rough 370 consensus", it is valid to allow for the development of SIP 371 extensions that are either not ready for Standards Track, but 372 might be understood for that role after some running code or are 373 private or proprietary in nature because a characteristic 374 motivating them is usage that is known not to fit the Internet 375 architecture for SIP. In the past, header fields associated with 376 those extensions were called "P-" header fields for "preliminary", 377 "private", or "proprietary". 379 However, the "P-" header field process has not served the purpose 380 for which it was designed -- namely, to restrict to closed 381 environments the usage of mechanisms the IETF would not (yet) 382 endorse for general usage. In fact, some "P-" header fields have 383 enjoyed widespread implementation; because of the "P-" prefix, 384 however, there seems to be no plausible migration path to 385 designate these as general-usage header fields without trying to 386 force implausible changes on large installed bases. 388 Accordingly, this specification deprecates the previous [RFC3427] 389 guidance on the creation of "P-" header fields.... The future use 390 of any header field name prefix ("P-" or "X-" or what have you) to 391 designate SIP header fields of limited applicability is 392 discouraged. 394 3.3. Architectural Compatibility 396 Since protocol extension mechanisms may impact interoperability, it 397 is important that they be architecturally compatible with the base 398 protocol. 400 As part of the definition of new extension mechanisms, it is 401 important to address whether the mechanisms make use of features as 402 envisaged by the original protocol designers, or whether a new 403 extension mechanism is being invented. If a new extension mechanism 404 is being invented, then architectural compatibility issues need to be 405 addressed. 407 To assist in the assessment of architectural compatibility, protocol 408 documents should provide guidelines explaining how extensions should 409 be performed, and guidance on the appropriate use of protocol 410 extension mechanisms should be developed. Protocol components that 411 are designed with the specific intention of allowing extensibility 412 should be clearly identified, with specific and complete instructions 413 on how to extend them. This includes the process for adequate review 414 of extension proposals: do they need community review and if so how 415 much and by whom? 417 Documents relying on extension mechanisms need to explicitly identify 418 the mechanisms being relied upon. For example, a document defining 419 new data elements should not implicitly define new data types or 420 protocol operations without explicitly describing those dependencies 421 and discussing their impact. Where extension guidelines are 422 available, mechanisms need to indicate whether they are compliant 423 with those guidelines and if not, why not. 425 Examples of extension guidelines documents include: 427 1. "Guidelines for Extending the Extensible Provisioning Protocol 428 (EPP)" [RFC3735], which provides guidelines for use of EPP's 429 extension mechanisms to define new features and object management 430 capabilities. 432 2. "Guidelines for Authors and Reviewers of MIB Documents" BCP 111 433 [RFC4181], which provides guidance to protocol designers creating 434 new MIB modules. 436 3. "Guidelines for Authors of Extensions to the Session Initiation 437 Protocol (SIP)" [RFC4485], which outlines guidelines for authors 438 of SIP extensions. 440 4. "Considerations for Lightweight Directory Access Protocol 441 (LDAP) Extensions" BCP 118 [RFC4521], which discusses 442 considerations for designers of LDAP extensions. 444 5. "RADIUS Design Guidelines" BCP 158 [RFC6158], which provides 445 guidelines for the design of attributes used by the Remote 446 Authentication Dial In User Service (RADIUS) protocol. 448 3.4. Protocol Variations 450 Protocol variations - specifications that look very similar to the 451 original but don't interoperate with each other or with the original 452 - are even more harmful to interoperability than extensions. In 453 general, such variations should be avoided. Causes of protocol 454 variations include incompatible protocol extensions, uncoordinated 455 protocol development, and poorly designed "profiles". 457 Protocol extension mechanisms should not be used to create 458 incompatible forks in development. An extension may lead to 459 interoperability failures unless the extended protocol correctly 460 supports all mandatory and optional features of the unextended base 461 protocol, and implementations of the base protocol operate correctly 462 in the presence of the extensions. In addition, it is necessary for 463 an extension to interoperate with other extensions. 465 As noted in "Uncoordinated Protocol Development Considered Harmful" 466 [RFC5704] Section 1, incompatible forks in development can result 467 from the uncoordinated adaptation of a protocol, parameter or code- 468 point: 470 In particular, the IAB considers it an essential principle of the 471 protocol development process that only one SDO maintains design 472 authority for a given protocol, with that SDO having ultimate 473 authority over the allocation of protocol parameter code-points 474 and over defining the intended semantics, interpretation, and 475 actions associated with those code-points. 477 3.4.1. Profiles 479 Profiling is a common technique for improving interoperability within 480 a target environment or set of scenarios. Generally speaking, there 481 are two approaches to profiling: 483 a) Removal or downgrading of normative requirements (thereby creating 484 potential interoperability problems); 486 b) Elevation of normative requirement levels (such as from a 487 MAY/SHOULD to a MUST) in order to improve interoperability by 488 narrowing potential implementation choices. 490 While approach a) is potentially harmful, approach b) may be 491 beneficial, but is typically only necessary when the underlying 492 protocol is ill-defined enough to permit non-interoperable yet 493 compliant implementations. 495 In order to avoid creating interoperability problems when profiled 496 implementations interact with others over the Global Internet, 497 profilers need to remain cognizant of the implications of removing 498 normative requirements. As noted in "Key words for use in RFCs to 499 Indicate Requirement Levels" [RFC2119] Section 6, imperatives are to 500 be used with care, and as a result, their removal within a profile is 501 likely to result in serious consequences: 503 Imperatives of the type defined in this memo must be used with 504 care and sparingly. In particular, they MUST only be used where 505 it is actually required for interoperation or to limit behavior 506 which has potential for causing harm (e.g., limiting 507 retransmissions) For example, they must not be used to try to 508 impose a particular method on implementors where the method is not 509 required for interoperability. 511 As noted in [RFC2119] Sections 3 and 4, recommendations cannot be 512 removed from profiles without serious consideration: 514 there may exist valid reasons in particular circumstances to 515 ignore a particular item, but the full implications must be 516 understood and carefully weighed before choosing a different 517 course. 519 Even the removal of optional features and requirements can have 520 consequences. As noted in [RFC2119] Section 5, implementations which 521 do not support optional features still retain the obligation to 522 ensure interoperation with implementations that do: 524 An implementation which does not include a particular option MUST 525 be prepared to interoperate with another implementation which does 526 include the option, though perhaps with reduced functionality. In 527 the same vein an implementation which does include a particular 528 option MUST be prepared to interoperate with another 529 implementation which does not include the option (except, of 530 course, for the feature the option provides.) 532 3.5. Testability 534 Experience has shown that it is insufficient merely to correctly 535 specify extensibility and backwards compatibility in an RFC. It is 536 also important that implementations respect the compatibility 537 mechanisms; if not, non-interoperable pairs of implementations may 538 arise. The TLS case study (Appendix A.3) shows how important this 539 can be. 541 In order to determine whether protocol extension mechanisms have been 542 properly implemented, testing is required. However, for this to be 543 possible, test cases need to be developed. If a base protocol 544 document specifies extension mechanisms but does not utilize them or 545 provide examples, it may not be possible to develop effective test 546 cases based on the base protocol specification alone. As a result, 547 base protocol implementations may not be properly tested and non- 548 compliant extension behavior may not be detected until these 549 implementations are widely deployed. 551 To encourage correct implementation of extension mechanisms, base 552 protocol specifications should clearly articulate the expected 553 behavior of extension mechanisms and should include examples of 554 correct and incorrect extension behavior. 556 3.6. Protocol Parameter Registration 558 An extension is often likely to make use of additional values added 559 to an existing IANA registry. To avoid conflicting usage of the same 560 value, as well as to prevent potential difficulties in determining 561 and transferring parameter ownership, it is essential that all new 562 values are registered. If this is not done, there is nothing to 563 prevent two different extensions picking the same value. When these 564 two extensions "meet" each other on the Internet, failure is 565 inevitable. 567 A surprisingly common case of this is misappropriation of assigned 568 Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP)) 569 registered port numbers. This can lead to a client for one service 570 attempting to communicate with a server for another service. 571 Numerous cases could be cited, but not without embarrassing specific 572 implementers. 574 For general rules see [RFC5226], and for specific rules and 575 registries see the individual protocol specification RFCs and the 576 IANA web site. While in theory a "standards track" or "IETF 577 consensus" parameter allocation policy may be instituted to encourage 578 protocol parameter registration or to improve interoperability, in 579 practice problems can arise if the procedures result in so much delay 580 that requesters give up and "self-allocate" by picking presumably- 581 unused code points. Where self-allocation is prevalent, the 582 information contained within registries may become inaccurate, 583 particularly when third parties are prohibited from updating entries 584 so as to improve accuracy. In these situations, it is important to 585 consider whether registration processes need to be changed to support 586 the role of a registry as "documentation of how the Internet is 587 operating". 589 3.6.1. Experimental and Local Use 591 In some cases, it may be appropriate to use values designated as 592 "experimental" or "local use" in early implementations of an 593 extension. For example, "Experimental Values in IPv4, IPv6, ICMPv4, 594 ICMPv6, UDP and TCP Headers" [RFC4727] discusses experimental values 595 for IP and transport headers, and "Definition of the Differentiated 596 Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] 597 defines experimental/local use ranges for differentiated services 598 code points. 600 Such values should be used with care and only for their stated 601 purpose: experiments and local use. They are unsuitable for 602 Internet-wide use, since they may be used for conflicting purposes 603 and thereby cause interoperability failures. Packets containing 604 experimental or local use values must not be allowed out of the 605 domain in which they are meaningful. 607 As noted in [RFC5226] Section 4.1: 609 For private or local use... No attempt is made to prevent multiple 610 sites from using the same value in different (and incompatible) 611 ways... assignments are not generally useful for broad 612 interoperability. It is the responsibility of the sites making 613 use of the Private Use range to ensure that no conflicts occur 614 (within the intended scope of use). 616 "Assigning Experimental and Testing Numbers Considered Useful" BCP 82 617 [RFC3692] Section 1 provides additional guidance on the use of 618 experimental code points: 620 Numbers in the experimentation range.... are not intended to be 621 used in general deployments or be enabled by default in products 622 or other general releases. In those cases where a product or 623 release makes use of an experimental number, the end user must be 624 required to explicitly enable the experimental feature and 625 likewise have the ability to chose and assign which number from 626 the experimental range will be used for a specific purpose (i.e., 627 so the end user can ensure that use of a particular number doesn't 628 conflict with other on-going uses). Shipping a product with a 629 specific value pre-enabled would be inappropriate and can lead to 630 interoperability problems when the chosen value collides with a 631 different usage, as it someday surely will. 633 From the above, it follows that it would be inappropriate for a 634 group of vendors, a consortia, or another Standards Development 635 Organization to agree among themselves to use a particular value 636 for a specific purpose and then agree to deploy devices using 637 those values. By definition, experimental numbers are not 638 guaranteed to be unique in any environment other than one where 639 the local system administrator has chosen to use a particular 640 number for a particular purpose and can ensure that a particular 641 value is not already in use for some other purpose. 643 3.7. Extensions to Critical Protocols 645 Some protocols (such as Domain Name Service (DNS) and Border Gateway 646 Protocol (BGP)) have become critical components of the Internet 647 infrastructure. When such protocols are extended, the potential 648 exists for negatively impacting the reliability and security of the 649 global Internet. 651 As a result, special care needs to be taken with these extensions, 652 such as taking explicit steps to isolate existing uses from new ones. 653 For example, this can be accomplished by requiring the extension to 654 utilize a different port or multicast address, or by implementing the 655 extension within a separate process, without access to the data and 656 control structures of the base protocol. 658 Experience has shown that even when a mechanism has proven benign in 659 other uses, unforseen issues may result when adding it to a critical 660 protocol. For example, both ISIS and OSPF support opaque Link State 661 Attributes (LSAs) which are propagated by intermediate nodes that 662 don't understand the LSA. Within Interior Gateway Protocols (IGPs), 663 support for opaque LSAs has proven useful without introducing 664 instability. 666 However, within BGP, 'attribute tunneling' has resulted in large 667 scale routing instabilities, since remote nodes may reset the LOCAL 668 session if the tunneled attributes are malformed or aren't 669 understood. This has required modification to BGP error handling, as 670 noted in "Error Handling for Optional Transitive Attribute BGP 671 Attributes" [Transitive]. 673 In general, when extending protocols with local failure conditions, 674 tunneling of attributes that may trigger failures in non-adjacent 675 nodes should be avoided. This is particularly problematic when the 676 originating node receives no indicators of remote failures it may 677 have triggered. 679 4. Considerations for the Base Protocol 681 Good extension design depends on a well designed base protocol. 682 Interoperability stems from a number of factors, including: 684 1. A well-written base protocol specification. Does the base 685 protocol specification make clear what an implementor needs to 686 support and does it define the impact that individual operations 687 (e.g. a message sent to a peer) will have when invoked? 689 2. Design for deployability. This includes understanding what 690 current implementations do and how a proposed extension will 691 interact with deployed systems. Is it clear when a proposed 692 extension (or its proposed usage) will operationally stress 693 existing implementations or the underlying protocol itself if 694 widely deployed? If this is not explained in the base protocol 695 specification, is this covered in an extension design guidelines 696 document? 698 3. Design for backward compatibility. Does the base protocol 699 specification describe how to determine the capabilities of a 700 peer, and negotiate the use of extensions? Does it indicate how 701 implementations handle extensions that they do not understand? Is 702 it possible for an extended implementation to negotiate with an 703 unextended peer to find a common subset of useful functions? 705 4. Respecting underlying architectural or security assumptions. 706 Is there a document describing the underlying architectural 707 assumptions, as well as considerations that have arisen in 708 operational experience? Or are there undocumented considerations 709 that have arisen as the result of operational experience, after 710 the original protocol was published? 712 For example, will backward compatibility issues arise if 713 extensions reverse the flow of data, allow formerly static 714 parameters to be changed on the fly, or change assumptions 715 relating to the frequency of reads/writes? 717 5. Minimizing impact on critical infrastructure. For a protocol 718 that represents a critical element of Internet infrastructure, it 719 is important to explain when it is appropriate to isolate new uses 720 of the protocol from existing ones. 722 For example, is it explained when a proposed extension (or usage) 723 has the potential for negatively impacting critical infrastructure 724 to the point where explicit steps would be appropriate to isolate 725 existing uses from new ones? 726 6. Data model extensions. Is there a document that explains when 727 a protocol extension is routine and when it represents a major 728 change? 730 For example, is it clear when a data model extension represents a 731 major versus a routine change? Are there guidelines describing 732 when an extension (such as a new data type) is likely to require a 733 code change within existing implementations? in -0.3i 735 4.1. Version Numbers 737 Any mechanism for extension by versioning must include provisions to 738 ensure interoperability, or at least clean failure modes. Imagine 739 someone creating a protocol and using a "version" field and 740 populating it with a value (1, let's say), but giving no information 741 about what would happen when a new version number appears in it. 742 That's bad protocol design and description; it should be clear what 743 the expectation is and how you test it. For example, stating that 744 1.X must be compatible with any version 1 code, but version 2 or 745 greater is not expected to be compatible, has different implications 746 than stating that version 1 must be a proper subset of version 2. 748 An example of an under-specified versioning mechanism is provided by 749 the MIME-Version header, originally defined in "MIME (Multipurpose 750 Internet Mail Extensions)" [RFC1341]. As noted in [RFC1341] Section 751 1: 753 A MIME-Version header field....uses a version number to declare 754 a message to be conformant with this specification and 755 allows mail processing agents to distinguish between such 756 messages and those generated by older or non-conformant software, 757 which is presumed to lack such a field. 759 Beyond this, [RFC1341] provided little guidance on versioning 760 behavior, or even the format of the MIME-Version header, which was 761 specified to contain "text". [RFC1521] which obsoleted [RFC1341], 762 better defined the format of the version field, but still did not 763 clarify the versioning behavior: 765 Thus, future format specifiers, which might replace or extend 766 "1.0", are constrained to be two integer fields, separated by a 767 period. If a message is received with a MIME-version value other 768 than "1.0", it cannot be assumed to conform with this 769 specification... 771 It is not possible to fully specify how a mail reader that 772 conforms with MIME as defined in this document should treat a 773 message that might arrive in the future with some value of MIME- 774 Version other than "1.0". However, conformant software is 775 encouraged to check the version number and at least warn the user 776 if an unrecognized MIME- version is encountered. 778 Thus, even though [RFC1521] defined a MIME-Version header with a 779 syntax suggestive of a "Major/Minor" versioning scheme, in practice 780 the MIME-Version header was little more than a decoration. 782 A better example is ROHC (Robust Header Compression). ROHCv1 783 [RFC3095] supports a certain set of profiles for compression 784 algorithms. But experience had shown that these profiles had 785 limitations, so the ROHC WG developed ROHCv2 [RFC5225]. A ROHCv1 786 implementation does not contain code for the ROHCv2 profiles. As the 787 ROHC WG charter said during the development of ROHCv2: 789 It should be noted that the v2 profiles will thus not be 790 compatible with the original (ROHCv1) profiles, which means less 791 complex ROHC implementations can be realized by not providing 792 support for ROHCv1 (over links not yet supporting ROHC, or by 793 shifting out support for ROHCv1 in the long run). Profile support 794 is agreed through the ROHC channel negotiation, which is part of 795 the ROHC framework and thus not changed by ROHCv2. 797 Thus in this case both backwards-compatible and backwards- 798 incompatible deployments are possible. The important point is a 799 clearly thought out approach to the question of operational 800 compatibility. In the past, protocols have utilized a variety of 801 strategies for versioning, many of which have proven problematic. 802 These include: 804 1. No versioning support. This approach is exemplified by 805 Extensible Authentication Protocol (EAP) [RFC3748] as well as 806 Remote Authentication Dial In User Service (RADIUS) [RFC2865], 807 both of which provide no support for versioning. While lack of 808 versioning support protects against the proliferation of 809 incompatible dialects, the need for extensibility is likely to 810 assert itself in other ways, so that ignoring versioning entirely 811 may not be the most forward thinking approach. 813 2. Highest mutually supported version (HMSV). In this approach, 814 implementations exchange the version numbers of the highest 815 version each supports, with the negotiation agreeing on the 816 highest mutually supported protocol version. This approach 817 implicitly assumes that later versions provide improved 818 functionality, and that advertisement of a particular version 819 number implies support for all lower version numbers. Where these 820 assumptions are invalid, this approach breaks down, potentially 821 resulting in interoperability problems. An example of this issue 822 occurs in Protected Extensible Authentication Protocol [PEAP] 823 where implementations of higher versions may not necessarily 824 provide support for lower versions. 826 3. Assumed backward compatibility. In this approach, 827 implementations may send packets with higher version numbers to 828 legacy implementations supporting lower versions, but with the 829 assumption that the legacy implementations will interpret packets 830 with higher version numbers using the semantics and syntax defined 831 for lower versions. This is the approach taken by Port-Based 832 Access Control [IEEE-802.1X]. For this approach to work, legacy 833 implementations need to be able to accept packets of known types 834 with higher protocol versions without discarding them; protocol 835 enhancements need to permit silent discard of unsupported 836 extensions; implementations supporting higher versions need to 837 refrain from mandating new features when encountering legacy 838 implementations. 840 4. Major/minor versioning. In this approach, implementations with 841 the same major version but a different minor version are assumed 842 to be backward compatible, but implementations are required to 843 negotiate a mutually supported major version number. This 844 approach assumes that implementations with a lower minor version 845 number but the same major version can safely ignore unsupported 846 protocol messages. 848 5. Min/max versioning. This approach is similar to HMSV, but 849 without the implied obligation for clients and servers to support 850 all versions back to version 1, in perpetuity. It allows clients 851 and servers to cleanly drop support for early versions when those 852 versions become so old that they are no longer relevant and no 853 longer required. In this approach, the client initiating the 854 connection reports the highest and lowest protocol versions it 855 understands. The server reports back the chosen protocol version: 857 a. If the server understands one or more versions in the client's 858 range, it reports back the highest mutually understood version. 860 b. If there is no mutual version, then the server reports back 861 some version that it does understand (selected as described 862 below). The connection is then typically dropped by client or 863 server, but reporting this version number first helps facilitate 864 useful error messages at the client end: 866 * If there is no mutual version, and the server speaks any 867 version higher than client max, it reports the lowest version it 868 speaks which is greater than the client max. The client can 869 then report to the user, "You need to upgrade to at least 870 version ." 872 * Else, the server reports the highest version it speaks. The 873 client can then report to the user, "You need to request the 874 server operator to upgrade to at least version ." 876 Protocols generally do not need any version-negotiation mechanism 877 more complicated than the mechanisms described here. The nature of 878 protocol version-negotiation mechanisms is that, by definition, they 879 don't get widespread real-world testing until *after* the base 880 protocol has been deployed for a while, and its deficiencies have 881 become evident. This means that, to be useful, a protocol version 882 negotiation mechanism should be simple enough that it can reasonably 883 be assumed that all the implementers of the first protocol version at 884 least managed to implement the version-negotiation mechanism 885 correctly. 887 4.2. Reserved Fields 889 Protocols commonly include one or more "reserved" fields, clearly 890 intended for future extensions. It is good practice to specify the 891 value to be inserted in such a field by the sender (typically zero) 892 and the action to be taken by the receiver when seeing some other 893 value (typically no action). In packet format diagrams, such fields 894 are typically labeled "MBZ", to be read as, "Must Be Zero on 895 transmission, Must Be Ignored on reception." 897 A common mistake of inexperienced protocol implementers is to think 898 that "MBZ" means that it's their software's job to verify that the 899 value of the field is zero on reception, and reject the packet if 900 not. This is a mistake, and such software will fail when it 901 encounters future versions of the protocol where these previously 902 reserved fields are given new defined meanings. Similarly, protocols 903 should carefully specify how receivers should react to unknown 904 extensions (headers, TLVs etc.), such that failures occur only when 905 that is truly the intended outcome. 907 4.3. Encoding Formats 909 Using widely-supported encoding formats leads to better 910 interoperability and easier extensibility. 912 As described in "IAB Thoughts on Encodings for International Domain 913 Names" [RFC6055], the number of encodings should be minimized and 914 complex encodings are generally a bad idea. As soon as one moves 915 outside the ASCII repertoire, issues relating to collation and/or 916 comparison arise that extensions must handle with care. 918 An example is the Simple Network Management Protocol (SNMP) Structure 919 of Managed Information (SMI). Guidelines exist for defining the 920 Management Information Base (MIB) objects that SNMP carries 921 [RFC4181]. Also, multiple textual conventions have been published, 922 so that MIB designers do not have to reinvent the wheel when they 923 need a commonly encountered construct. For example, the "Textual 924 Conventions for Internet Network Addresses" [RFC4001] can be used by 925 any MIB designer needing to define objects containing IP addresses, 926 thus ensuring consistency as the body of MIBs is extended. 928 4.4. Parameter Space Design 930 In some protocols the parameter space is either infinite (e.g. Header 931 field names) or sufficiently large that it is unlikely to be 932 exhausted. In other protocols, the parameter space is finite, and in 933 some cases, has proven inadequate to accommodate demand. Common 934 mistakes include: 936 a. A version field that is too small (e.g. two bits or less). When 937 designing a version field, existing as well as potential versions of 938 a protocol need to be taken into account. For example, if a protocol 939 is being standardized for which there are existing implementations 940 with known interoperability issues, more than one version for "pre- 941 standard" implementations may be required. If two "pre-standard" 942 versions are required in addition to a version for an IETF standard, 943 then a two-bit version field would only leave one additional version 944 code-point for a future update, which could be insufficient. This 945 problem was encountered during the development of the PEAPv2 protocol 946 [PEAP]. 948 b. A small parameter space (e.g. 8-bits or less) along with a First 949 Come, First Served (FCFS) allocation policy. In general, an FCFS 950 allocation policy is only appropriate in situations where parameter 951 exhaustion is highly unlikely. In situations where substantial 952 demand is anticipated within a parameter space, the space should 953 either be designed to be sufficient to handle that demand, or vendor 954 extensibility should be provided to enable vendors to self-allocate. 955 The combination of a small parameter space, an FCFS allocation 956 policy, and no support for vendor extensibility is particularly 957 likely to prove ill-advised. An example of such a combination was 958 the design of the original 8-bit EAP Method Type space [RFC2284]. 960 Once the potential for parameter exhaustion becomes apparent, it is 961 important that it be addressed as quickly as possible. Protocol 962 changes can take years to appear in implementations and by then the 963 exhaustion problem could become acute. 965 Options for addressing a protocol parameter exhaustion problem 966 include: 968 Rethinking the allocation regime 969 Where it becomes apparent that the size of a parameter space is 970 insufficient to meet demand, it may be necessary to rethink the 971 allocation mechanism, in order to prevent or delay parameter space 972 exhaustion. In revising parameter allocation mechanisms, it is 973 important to consider both supply and demand aspects so as to avoid 974 unintended consequences such as self-allocation or the development 975 of black markets for the re-sale of protocol parameters. 977 For example, a few years after approval of RFC 2284 [RFC2284], it 978 became clear that the combination of a FCFS allocation policy and 979 lack of support for vendor-extensions had created the potential for 980 exhaustion of the EAP Method Type space within a few years. To 981 address the issue, [RFC3748] Section 6.2 changed the allocation 982 policy for EAP Method Types from FCFS to Expert Review, with 983 Specification Required. Since this allocation policy revision did 984 not change the demand for EAP Method Types, it would have been 985 likely to result in self-allocation within the standards space, had 986 mechanisms not been provided to expand the method type space 987 (including support for vendor-specific method types). 989 Support for vendor-specific parameters 990 If the demand that cannot be accommodated is being generated by 991 vendors, merely making allocation harder could make things worse if 992 this encourages vendors to self-allocate, creating interoperability 993 problems. In such a situation, support for vendor-specific 994 parameters should be considered, allowing each vendor to self- 995 allocate within their own vendor-specific space based on a vendor's 996 Private Enterprise Code (PEC). For example, in the case of the EAP 997 Method Type space, [RFC3748] Section 6.2 also provided for an 998 Expanded Type space for "functions specific only to one vendor's 999 implementation". 1001 Extensions to the parameter space 1002 If the goal is to stave off exhaustion in the face of high demand, 1003 a larger parameter space may be helpful. Where vendor-specific 1004 parameter support is available, this may be achieved by allocating 1005 an PEC for IETF use. Otherwise it may be necessary to try to extend 1006 the size of the parameter fields, which could require a new 1007 protocol version or other substantial protocol changes. 1009 Parameter reclamation 1010 In order to gain time, it may be necessary to reclaim unused 1011 parameters. However, it may not be easy to determine whether a 1012 parameter that has been allocated is in use or not, particularly if 1013 the entity that obtained the allocation no longer exists or has 1014 been acquired (possibly multiple times). 1016 Parameter Transfer 1017 When all the above mechanisms have proved infeasible and parameter 1018 exhaustion looms in the near future, enabling the transfer of 1019 ownership of protocol parameters can be considered as a means for 1020 improving allocation efficiency. However, enabling transfer of 1021 parameter ownership can be far from simple if the parameter 1022 allocation process was not originally designed to enable title 1023 searches and ownership transfers. 1025 A parameter allocation process designed to uniquely allocate code- 1026 points is fundamentally different from one designed to enable title 1027 search and transfer. If the only goal is to ensure that a 1028 parameter is not allocated more than once, the parameter registry 1029 will only need to record the initial allocation. On the other 1030 hand, if the goal is to enable transfer of ownership of a protocol 1031 parameter, then it is important not only to record the initial 1032 allocation, but also to track subsequent ownership changes, so as 1033 to make it possible to determine and transfer title. Given the 1034 difficulty of converting from a unique allocation regime to one 1035 requiring support for title search and ownership transfer, it is 1036 best for the desired capabilities to be carefully thought through 1037 at the time of registry establishment. 1039 4.5. Cryptographic Agility 1041 Extensibility with respect to cryptographic algorithms is desirable 1042 in order to provide resilience against the compromise of any 1043 particular algorithm. "Guidance for Authentication, Authorization, 1044 and Accounting (AAA) Key Management" BCP 132 [RFC4962] Section 3 1045 provides some basic advice: 1047 The ability to negotiate the use of a particular cryptographic 1048 algorithm provides resilience against compromise of a particular 1049 cryptographic algorithm... This is usually accomplished by 1050 including an algorithm identifier and parameters in the protocol, 1051 and by specifying the algorithm requirements in the protocol 1052 specification. While highly desirable, the ability to negotiate 1053 key derivation functions (KDFs) is not required. For 1054 interoperability, at least one suite of mandatory-to-implement 1055 algorithms MUST be selected... 1057 This requirement does not mean that a protocol must support both 1058 public-key and symmetric-key cryptographic algorithms. It means 1059 that the protocol needs to be structured in such a way that 1060 multiple public-key algorithms can be used whenever a public-key 1061 algorithm is employed. Likewise, it means that the protocol needs 1062 to be structured in such a way that multiple symmetric-key 1063 algorithms can be used whenever a symmetric-key algorithm is 1064 employed. 1066 In practice, the most difficult challenge in providing cryptographic 1067 agility is providing for a smooth transition in the event that a 1068 mandatory-to-implement algorithm is compromised. Since it may take 1069 significant time to provide for widespread implementation of a 1070 previously undeployed alternative, it is often advisable to recommend 1071 implementation of alternative algorithms of distinct lineage in 1072 addition to those made mandatory-to-implement, so that an alternative 1073 algorithm is readily available. If such a recommended alternative is 1074 not in place, then it would be wise to issue such a recommendation as 1075 soon as indications of a potential weakness surface. This is 1076 particularly important in the case of potential weakness in 1077 algorithms used to authenticate and integrity-protect the 1078 cryptographic negotiation itself, such as KDFs or message integrity 1079 checks (MICs). Without secure alternatives to compromised KDF or MIC 1080 algorithms, it may not be possible to secure the cryptographic 1081 negotiation while retaining backward compatibility. 1083 4.6. Transport 1085 In the past, IETF protocols have been specified to operate over 1086 multiple transports. Often the protocol was originally specified to 1087 utilize a single transport, but limitations were discovered in 1088 subsequent deployment, so that additional transports were 1089 subsequently specified. 1091 In a number of cases, the protocol was originally specified to 1092 operate over UDP, but subsequent operation disclosed one or more of 1093 the following issues, leading to the specification of alternative 1094 transports: 1096 a. Payload fragmentation (often due to the introduction of 1097 extensions or additional usage scenarios); 1099 b. Problems with congestion control, transport reliability or 1100 efficiency; 1102 c. Lack of deployment in multicast scenarios, which had been a 1103 motivator for UDP transport. 1105 On the other hand, there are also protocols that were originally 1106 specified to operate over reliable transport that have subsequently 1107 defined transport over UDP, due to one or more of the following 1108 issues: 1110 d. NAT traversal concerns that were more easily addressed with UDP 1111 transport; 1113 e. Scalability problems, which could be improved by UDP transport. 1115 Since specification of a single transport offers the highest 1116 potential for interoperability, protocol designers should carefully 1117 consider not only initial but potential future requirements in the 1118 selection of a transport protocol. Where UDP transport is selected, 1119 the guidance provided in "Unicast UDP Usage Guidelines for 1120 Application Designers" [RFC5405]. should be taken into account. 1122 After significant deployment has occurred, there are few satisfactory 1123 options for addressing problems with the originally selected 1124 transport. While specification of additional transports is possible, 1125 removal of a widely implemented transport protocol is likely to 1126 result in interoperability problems and should be avoided. 1128 Mandating support for the initially selected transport, while 1129 designating additional transports as optional may have limitations. 1130 Since optional transport protocols are typically introduced due to 1131 the advantages they afford in certain scenarios, in those situations 1132 implementations not supporting optional transport protocols may 1133 exhibit degraded performance or may even fail. 1135 While mandating support for multiple transport protocols may appear 1136 attractive, designers need to realistically evaluate the likelihood 1137 that implementers will conform to the requirements. For example, 1138 where resources are limited (such as in embedded systems), 1139 implementers may choose to only support a subset of the mandated 1140 transport protocols, resulting in non-interoperable protocol 1141 variants. 1143 4.7. Handling of Unknown Extensions 1145 IETF protocols have utilized several techniques for handling of 1146 unknown extensions. One technique (often used for vendor-specific 1147 extensions) is to specify that unknown extensions be "silently 1148 discarded". 1150 While this approach can deliver a high level of interoperability, 1151 there are situations in which it is problematic. For example, where 1152 security functionality is involved, "silent discard" may not be 1153 satisfactory, particularly if the recipient does not provide feedback 1154 as to whether it supports the extension or not. This can lead to 1155 operational security issues that are difficult to detect and correct, 1156 as noted in Appendix A.2 and "common RADIUS Implementation Issues and 1157 Suggested Fixes" [RFC5080] Section 2.5. 1159 In order to ensure that a recipient supports an extension, a 1160 recipient encountering an unknown extension may be required to 1161 explicitly reject it and to return an error, rather than proceeding. 1162 This can be accomplished via a "Mandatory" bit in a TLV-based 1163 protocol such as L2TP [RFC2661], or a "Require" or "Proxy-Require" 1164 header in a text-based protocol such as SIP [RFC3261] or HTTP 1165 [RFC2616]. 1167 Since a mandatory extension can result in an interoperability failure 1168 when communicating with a party that does not support the extension, 1169 this designation may not be permitted for vendor-specific extensions, 1170 and may only be allowed for standards-track extensions. To enable 1171 fallback operation with degraded functionality, it is good practice 1172 for the recipient to indicate the reason for the failure, including a 1173 list of unsupported extensions. The initiator can then retry without 1174 the offending extensions. 1176 Typically only the recipient will find itself in the position of 1177 rejecting a mandatory extension, since the initiator can explicitly 1178 indicate which extensions are supported, with the recipient choosing 1179 from among the supported extensions. This can be accomplished via an 1180 exchange of TLVs, such as in IKEv2 [RFC5996] or Diameter [RFC3588], 1181 or via use of "Accept", "Accept-Encoding", "Accept-Language", "Allow" 1182 and "Supported" headers in a text-based protocol such as SIP 1183 [RFC3261] or HTTP [RFC2616]. 1185 5. Security Considerations 1187 An extension must not introduce new security risks without also 1188 providing adequate counter-measures, and in particular it must not 1189 inadvertently defeat security measures in the unextended protocol. 1190 Thus, the security analysis for an extension needs to be as thorough 1191 as for the original protocol - effectively it needs to be a 1192 regression analysis to check that the extension doesn't inadvertently 1193 invalidate the original security model. 1195 This analysis may be simple (e.g. adding an extra opaque data element 1196 is unlikely to create a new risk) or quite complex (e.g. adding a 1197 handshake to a previously stateless protocol may create a completely 1198 new opportunity for an attacker). 1200 When the extensibility of a design includes allowing for new and 1201 presumably more powerful cryptographic algorithms to be added, 1202 particular care is needed to ensure that the result is in fact 1203 increased security. For example, it may be undesirable from a 1204 security viewpoint to allow negotiation down to an older, less secure 1205 algorithm. 1207 6. IANA Considerations 1209 [RFC Editor: please remove this section prior to publication.] 1211 This document has no IANA Actions. 1213 7. References 1215 7.1. Normative References 1217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1218 Requirement Levels", BCP 14, RFC 2119, March 1997. 1220 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for 1221 Protocol Extensions and Variations", BCP 125, RFC 4775, 1222 December 2006. 1224 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1225 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 1227 7.2. Informative References 1229 [IEEE-802.1X] 1230 Institute of Electrical and Electronics Engineers, "Local and 1231 Metropolitan Area Networks: Port-Based Network Access 1232 Control", IEEE Standard 802.1X-2004, December 2004. 1234 [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. and 1235 S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", 1236 draft-josefsson-pppext-eap-tls-eap-10.txt, Expired Internet 1237 draft (work in progress), October 2004. 1239 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text 1240 messages", STD 11, RFC 822, August 1982. 1242 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 1243 Harmful", RFC 1263, October 1991. 1245 [RFC1341] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet 1246 Mail Extensions): Mechanisms for Specifying and Describing 1247 the Format of Internet Message Bodies", RFC 1341, June 1992. 1249 [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 1250 Mail Extensions) Part One: Mechanisms for Specifying and 1251 Describing the Format of Internet Message Bodies", RFC 1521, 1252 September 1993. 1254 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1255 Extensions", RFC 2132, March 1997. 1257 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1258 2246, January 1999. 1260 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 1261 Protocol (EAP)", RFC 2284, March 1998. 1263 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition 1264 of the Differentiated Services Field (DS Field) in the IPv4 1265 and IPv6 Headers", RFC 2474, December 1998. 1267 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 1268 L., Leach, P., and T. Berners-Lee, "Hypertext Transfer 1269 Protocol -- HTTP/1.1", RFC 2616, June 1999. 1271 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., 1272 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 1273 2661, August 1999. 1275 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",RFC 2671, 1276 August 1999. 1278 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1280 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1281 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1282 2000. 1284 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1285 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., 1286 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, 1287 T., Yoshimura, T., and H. Zheng, "RObust Header Compression 1288 (ROHC): Framework and four profiles: RTP, UDP, ESP, and 1289 uncompressed", RFC 3095, July 2001. 1291 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1292 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1293 Session Initiation Protocol", RFC 3261, June 2002. 1295 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and 1296 B. Rosen, "Change Process for the Session Initiation Protocol 1297 (SIP)", BCP 67, RFC 3427, December 2002. 1299 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1300 Authentication Dial In User Service)", RFC 3575, July 2003. 1302 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1303 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1305 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) 1306 Types", RFC 3597, September 2003. 1308 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1309 Considered Useful", BCP 82, RFC 3692, January 2004. 1311 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 1312 Provisioning Protocol (EPP)", RFC 3735, March 2004. 1314 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1315 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 1316 3748, June 2004. 1318 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", RFC 3935, 1319 October 2004. 1321 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1322 Schoenwaelder, "Textual Conventions for Internet Network 1323 Addresses", RFC 4001, February 2005. 1325 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1326 Documents", BCP 111, RFC 4181, September 2005. 1328 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1329 and T. Wright, "Transport Layer Security (TLS) Extensions", 1330 RFC 4366, April 2006. 1332 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of 1333 Extensions to the Session Initiation Protocol (SIP)", RFC 1334 4485, May 2006. 1336 [RFC4521] Zeilenga, K., "Considerations for Lightweight Directory 1337 Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, June 1338 2006. 1340 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1341 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1343 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 1344 Multiprotocol Label Switching (MPLS) and Generalized MPLS 1345 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 1346 2007. 1348 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1349 Authorization, and Accounting (AAA) Key Management", BCP 132, 1350 RFC 4962, July 2007. 1352 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial 1353 In User Service (RADIUS) Implementation Issues and Suggested 1354 Fixes", RFC 5080, December 2007. 1356 [RFC5218] Thaler, D., and B. Aboba, "What Makes for a Successful 1357 Protocol?", RFC 5218, July 2008. 1359 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 1360 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP- 1361 Lite", RFC 5225, April 2008. 1363 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1364 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1366 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1367 October 2008. 1369 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1370 for Application Designers", RFC 5405 (BCP 145), November 1371 2008. 1373 [RFC5704] Bryant, S. and M. Morrow, "Uncoordinated Protocol Development 1374 Considered Harmful", RFC 5704, November 2009. 1376 [RFC5727] Peterson, J., Jennings, C. and R. Sparks, "Change Process for 1377 the Session Initiation Protocol (SIP) and the Real-time 1378 Applications and Infrastructure Area", BCP 67, RFC 5727, 1379 March 2010. 1381 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet 1382 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 1383 2010. 1385 [RFC6055] Thaler, D., Klensin, J. and S. Cheshire, "IAB Thoughts on 1386 Encodings for Internationalized Domain Names", RFC 6055, 1387 February 2011. 1389 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, 1390 RFC 6158, March 2011. 1392 [Transitive] 1393 Scudder, J., Chen, E., Mohapatra, P. and K. Patel, "Revised 1394 Error Handling for BGP UPDATE Messages", Internet draft (work 1395 in progress), draft-ietf-idr-optional-transitive-04, October, 1396 2011. 1398 Acknowledgments 1400 This document is heavily based on an earlier draft under a different 1401 title by Scott Bradner and Thomas Narten. 1403 That draft stated: The initial version of this document was put 1404 together by the IESG in 2002. Since then, it has been reworked in 1405 response to feedback from John Loughney, Henrik Levkowetz, Mark 1406 Townsley, Randy Bush and others. 1408 Valuable comments and suggestions on the current form of the document 1409 were made by Loa Andersson, Jari Arkko, Leslie Daigle, Phillip 1410 Hallam-Baker, Ted Hardie, Alfred Hoenes, John Klensin, Danny 1411 McPherson, Eric Rescorla, Adam Roach and Pekka Savola. 1413 The text on TLS experience was contributed by Yngve Pettersen. 1415 IAB Members at the Time of Approval 1417 Bernard Aboba 1418 Ross Callon 1419 Alissa Cooper 1420 Spencer Dawkins 1421 Joel Halpern 1422 Russ Housley 1423 David Kessens 1424 Olaf Kolkman 1425 Danny McPherson 1426 Jon Peterson 1427 Andrei Robachevsky 1428 Dave Thaler 1429 Hannes Tschofenig 1431 Appendix A. Examples 1433 This section discusses some specific examples, as case studies. 1435 A.1. Already documented cases 1437 There are certain documents that specify a change process or describe 1438 extension considerations for specific IETF protocols: 1440 The SIP change process [RFC3427], [RFC4485], [RFC5727] 1441 The (G)MPLS change process (mainly procedural) [RFC4929] 1442 LDAP extensions [RFC4521] 1443 EPP extensions [RFC3735] 1444 DNS extensions [RFC2671][RFC3597] 1445 SMTP extensions [RFC5321] 1447 It is relatively common for MIBs, which are all in effect extensions 1448 of the SMI data model, to be defined or extended outside the IETF. 1449 BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. 1451 A.2. RADIUS Extensions 1453 The RADIUS [RFC2865] protocol was designed to be extensible via 1454 addition of Attributes to a Data Dictionary on the server, without 1455 requiring code changes. However, this extensibility model assumed 1456 that Attributes would conform to a limited set of data types and that 1457 vendor extensions would be limited to use by vendors, in situations 1458 in which interoperability was not required. Subsequent developments 1459 have stretched those assumptions. 1461 Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism 1462 for Vendor-Specific extensions (Attribute 26), and states that use of 1463 Vendor-Specific extensions: 1465 should be encouraged instead of allocation of global attribute 1466 types, for functions specific only to one vendor's implementation 1467 of RADIUS, where no interoperability is deemed useful. 1469 However, in practice usage of Vendor-Specific Attributes (VSAs) has 1470 been considerably broader than this. In particular, VSAs have been 1471 used by Standards Development Organizations (SDOs) to define their 1472 own extensions to the RADIUS protocol. 1474 This has caused a number of problems. With respect to VSAs, 1475 [RFC2865] Section 5.26 states: 1477 Servers not equipped to interpret the vendor-specific information 1478 sent by a client MUST ignore it (although it may be reported). 1480 Clients which do not receive desired vendor-specific information 1481 SHOULD make an attempt to operate without it, although they may do 1482 so (and report they are doing so) in a degraded mode. 1484 However, since VSAs do not contain a "mandatory" bit, RADIUS clients 1485 and servers may not know whether it is safe to ignore unknown VSAs. 1486 For example, in the case where the VSAs pertain to security (e.g. 1487 Filters), it may not be safe to ignore them. As a result, "Common 1488 Remote Authentication Dial In User Service (RADIUS) Implementation 1489 Issues and Suggested Fixes" [RFC5080] Section 2.5 includes a detailed 1490 discussion of this issue, including the following caution: 1492 To avoid misinterpretation of service requests encoded within 1493 VSAs, RADIUS servers SHOULD NOT send VSAs containing service 1494 requests to RADIUS clients that are not known to understand them. 1495 For example, a RADIUS server should not send a VSA encoding a 1496 filter without knowledge that the RADIUS client supports the VSA. 1498 Since it was not envisaged that multi-vendor VSA implementations 1499 would need to interoperate, the RADIUS specification [RFC2865] does 1500 not define the data model for VSAs, and allows multiple sub- 1501 attributes to be included within a single Attribute of type 26. 1502 Since this enables VSAs to be defined which would not be supportable 1503 by current implementations if placed within the standard RADIUS 1504 attribute space, this has caused problems in standardizing widely 1505 deployed VSAs, as discussed in "RADIUS Design Guidelines" BCP 158 1506 [RFC6158]. 1508 In addition to extending RADIUS by use of VSAs, SDOs have also 1509 defined new values of the Service-Type attribute in order to create 1510 new RADIUS commands. Since the RADIUS specification [RFC2865] 1511 defined Service-Type values as being allocated First Come, First 1512 Served (FCFS), this essentially enabled new RADIUS commands to be 1513 allocated without IETF review. This oversight has since been fixed 1514 in "IANA Considerations for RADIUS" [RFC3575]. 1516 A.3. TLS Extensions 1518 The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape 1519 to be used to secure online transactions on the Internet. It was 1520 later replaced by SSL v3, also developed by Netscape. SSL v3 was 1521 then further developed by the IETF as the Transport Layer Security 1522 (TLS) 1.0 [RFC2246]. 1524 The SSL v3 protocol was not explicitly specified to be extended. 1525 Even TLS 1.0 did not define an extension mechanism explicitly. 1526 However, extension "loopholes" were available. Extension mechanisms 1527 were finally defined in "Transport Layer Security (TLS) Extensions" 1529 [RFC4366]: 1531 o New versions 1532 o New cipher suites 1533 o Compression 1534 o Expanded handshake messages 1535 o New record types 1536 o New handshake messages 1538 The protocol also defines how implementations should handle unknown 1539 extensions. 1541 Of the above extension methods, new versions and expanded handshake 1542 messages have caused the most interoperability problems. 1543 Implementations are supposed to ignore unknown record types but to 1544 reject unknown handshake messages. 1546 The new version support in SSL/TLS includes a capability to define 1547 new versions of the protocol, while allowing newer implementations to 1548 communicate with older implementations. As part of this 1549 functionality some Key Exchange methods include functionality to 1550 prevent version rollback attacks. 1552 The experience with this upgrade functionality in SSL and TLS is 1553 decidedly mixed: 1555 o SSL v2 and SSL v3/TLS are not compatible. It is possible to use 1556 SSL v2 protocol messages to initiate a SSL v3/TLS connection, but 1557 it is not possible to communicate with a SSL v2 implementation 1558 using SSL v3/TLS protocol messages. 1559 o There are implementations that refuse to accept handshakes using 1560 newer versions of the protocol than they support. 1561 o There are other implementations that accept newer versions, but 1562 have implemented the version rollback protection clumsily. 1564 The SSL v2 problem has forced SSL v3 and TLS clients to continue to 1565 use SSL v2 Client Hellos for their initial handshake with almost all 1566 servers until 2006, much longer than would have been desirable, in 1567 order to interoperate with old servers. 1569 The problem with incorrect handling of newer versions has also forced 1570 many clients to actually disable the newer protocol versions, either 1571 by default, or by automatically disabling the functionality, to be 1572 able to connect to such servers. Effectively, this means that the 1573 version rollback protection in SSL and TLS is non-existent if talking 1574 to a fatally compromised older version. 1576 SSL v3 and TLS also permitted expansion of the Client Hello and 1577 Server Hello handshake messages. This functionality was fully 1578 defined by the introduction of TLS Extensions, which makes it 1579 possible to add new functionality to the handshake, such as the name 1580 of the server the client is connecting to, request certificate status 1581 information, indicate Certificate Authority support, maximum record 1582 length, etc. Several of these extensions also introduce new 1583 handshake messages. 1585 It has turned out that many SSL v3 and TLS implementations that do 1586 not support TLS Extensions, did not, as required by the protocol 1587 specifications, ignore the unknown extensions, but instead failed to 1588 establish connections. Several of the implementations behaving in 1589 this manner are used by high profile Internet sites, such as online 1590 banking sites, and this has caused a significant delay in the 1591 deployment of clients supporting TLS Extensions, and several of the 1592 clients that have enabled support are using heuristics that allow 1593 them to disable the functionality when they detect a problem. 1595 Looking forward, the protocol version problem, in particular, can 1596 cause future security problems for the TLS protocol. The strength of 1597 the digest algorithms (MD5 and SHA-1) used by SSL and TLS is 1598 weakening. If MD5 and SHA-1 weaken to the point where it is feasible 1599 to mount successful attacks against older SSL and TLS versions, the 1600 current error recovery used by clients would become a security 1601 vulnerability (among many other serious problems for the Internet). 1603 To address this issue, TLS 1.2 [RFC5246] makes use of a newer 1604 cryptographic hash algorithm (SHA-256) during the TLS handshake by 1605 default. Legacy ciphersuites can still be used to protect 1606 application data, but new ciphersuites are specified for data 1607 protection as well as for authentication within the TLS handshake. 1608 The hashing method can also be negotiated via a Hello extension. 1609 Implementations are encouraged to implement new ciphersuites, and to 1610 enable the negotiation of the ciphersuite used during a TLS session 1611 to be governed by policy, thus enabling a more rapid transition away 1612 from weakened ciphersuites. 1614 The lesson to be drawn from this experience is that it isn't 1615 sufficient to design extensibility carefully; it must also be 1616 implemented carefully by every implementer, without exception. Test 1617 suites and certification programs can help provide incentives for 1618 implementers to pay attention to implementing extensibility 1619 mechanisms correctly. 1621 A.4. L2TP Extensions 1623 Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value 1624 Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol 1625 itself. However, it should be noted that L2TP message types are 1626 identified by a Message Type AVP (Attribute Type 0) with specific AVP 1627 values indicating the actual message type. Thus, extensions relating 1628 to Message Type AVPs would likely be considered major extensions. 1630 L2TP also provides for Vendor-Specific AVPs. Because everything in 1631 L2TP is encoded using AVPs, it would be easy to define vendor- 1632 specific AVPs that would be considered major extensions. 1634 L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP 1635 messages containing AVPs they do not understand but that have the 1636 mandatory bit set, are expected to reject the message and terminate 1637 the tunnel or session the message refers to. This leads to 1638 interesting interoperability issues, because a sender can include a 1639 vendor-specific AVP with the M-bit set, which then causes the 1640 recipient to not interoperate with the sender. This sort of behavior 1641 is counter to the IETF ideals, as implementations of the IETF 1642 standard should interoperate successfully with other implementations 1643 and not require the implementation of non-IETF extensions in order to 1644 interoperate successfully. Section 4.2 of the L2TP specification 1645 [RFC2661] includes specific wording on this point, though there was 1646 significant debate at the time as to whether such language was by 1647 itself sufficient. 1649 Fortunately, it does not appear that the potential problems described 1650 above have yet become a problem in practice. At the time of this 1651 writing, the authors are not aware of the existence of any vendor- 1652 specific AVPs that also set the M-bit. 1654 Change log [RFC Editor: please remove this section] 1656 -10: 2012-2-12. Resolved issues 106 and 108. 1658 -09: 2011-10-30. Resolved additional issues. 1660 -08: 2011-10-22. Resolved additional issues. 1662 -07: 2011-7-24. Resolved issues raised in Call for Comment. 1664 -06: 2011-3-1. Incorporated corrections and organizational 1665 improvements. 1667 -05: 2011-2-4. Added to the security considerations section. 1669 -04: 2011-2-1. Added a section on cryptographic agility. Additional 1670 reorganization. 1672 -03: 2011-1-25. Updates and reorganization to address reviewer 1673 comments. 1675 -02: 2010-7-12. Updates by Bernard Aboba 1677 -01: 2010-4-7. Updates by Stuart Cheshire. 1679 draft-iab-extension-recs-00: 2009-4-24. Updated boilerplate, 1680 author list. 1682 -04: 2008-10-24. Updated author addresses, editorial fixes. 1684 -03: 2008-10-17. Updated references, added material relating to 1685 versioning. 1687 -02: 2007-06-15. Reorganized Sections 2 and 3. 1689 -01: 2007-03-04. Updated according to comments, especially the 1690 wording about TLS, added various specific examples. 1692 draft-carpenter-extension-recs-00: original version, 2006-10-12. 1693 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 1694 focusing on architectural issues; the procedural issues were moved to 1695 RFC 4775. 1697 Authors' Addresses 1699 Brian Carpenter 1700 Department of Computer Science 1701 University of Auckland 1702 PB 92019 1703 Auckland, 1142 1704 New Zealand 1706 Email: brian.e.carpenter@gmail.com 1708 Bernard Aboba 1709 Microsoft Corporation 1710 One Microsoft Way 1711 Redmond, WA 98052 1713 EMail: bernard_aboba@hotmail.com 1715 Stuart Cheshire 1716 Apple Computer, Inc. 1717 1 Infinite Loop 1718 Cupertino, CA 95014 1720 EMail: cheshire@apple.com