rfc9170.original.xml   rfc9170.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc toc="yes"?> -iab-use-it-or-lose-it-04" number="9170" obsoletes="" updates="" submissionType=
<?rfc sortrefs="yes"?> "IAB" category="info" consensus="true" xml:lang="en" tocInclude="true" sortRefs=
<?rfc symrefs="yes"?> "true" symRefs="true" version="3">
<?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-iab-use-it-or-lose-it-04" category="info" obsoletes="" updates="" submissionTyp
e="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version=
"3">
<!-- xml2rfc v2v3 conversion 3.10.0 -->
<front> <front>
<title abbrev="Use It Or Lose It">Long-term Viability of Protocol Extension <title abbrev="Use It or Lose It">Long-Term Viability of Protocol Extension
Mechanisms</title> Mechanisms</title>
<seriesInfo name="Internet-Draft" value="draft-iab-use-it-or-lose-it-04"/> <seriesInfo name="RFC" value="9170"/>
<author initials="M." surname="Thomson" fullname="Martin Thomson"> <author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization>
<address> <address>
<email>mt@lowentropy.net</email> <email>mt@lowentropy.net</email>
</address> </address>
</author> </author>
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> <author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple</organization>
<address> <address>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<date year="2021" month="October" day="13"/> <date year="2021" month="December"/>
<keyword>Extensions</keyword>
<keyword>versions</keyword>
<keyword>grease</keyword>
<abstract> <abstract>
<t>The ability to change protocols depends on exercising the extension and <t>The ability to change protocols depends on exercising the extension
version and version-negotiation mechanisms that support change. This document
negotiation mechanisms that support change. This document explores how regular explores how regular use of new protocol features can ensure that it
use of new protocol features can ensure that it remains possible to deploy remains possible to deploy changes to a protocol. Examples are given
changes to a protocol. Examples are given where lack of use caused changes to be where lack of use caused changes to be more difficult or costly.</t>
more difficult or costly.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
EDM Program mailing list (edm@iab.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ed
m/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/intarchboard/use-it-or-lose-it"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>A successful protocol <xref target="SUCCESS" format="default"/> needs t <t>A successful protocol <xref target="RFC5218" format="default"/> needs
o change in ways that allow it to change in ways that allow it to continue to fulfill the changing
to continue to fulfill the changing needs of its users. New use cases, needs of its users. New use cases, conditions, and constraints on the
conditions and constraints on the deployment of a protocol can render a protocol deployment of a protocol can render a protocol that does not change
that does not change obsolete.</t> obsolete.</t>
<t>Usage patterns and requirements for a protocol shift over time. In res ponse, <t>Usage patterns and requirements for a protocol shift over time. In res ponse,
implementations might adjust usage patterns within the constraints of the implementations might adjust usage patterns within the constraints of the
protocol, the protocol could be extended, or a replacement protocol might be protocol, the protocol could be extended, or a replacement protocol might be
developed. Experience with Internet-scale protocol deployment shows that each developed. Experience with Internet-scale protocol deployment shows that each
option comes with different costs. <xref target="TRANSITIONS" format="default"/ > examines the option comes with different costs. <xref target="RFC8170" format="default"/> ex amines the
problem of protocol evolution more broadly.</t> problem of protocol evolution more broadly.</t>
<t>An extension point is a mechanism that allows a protocol to be changed or <t>An extension point is a mechanism that allows a protocol to be changed or
enhanced. This document examines the specific conditions that determine whether enhanced. This document examines the specific conditions that determine whether
protocol maintainers have the ability to design and deploy new or modified protocol maintainers have the ability to design and deploy new or modified
protocols via their specified extension points. <xref target="implementations" format="default"/> highlights protocols via their specified extension points. <xref target="implementations" format="default"/> highlights
some historical examples of difficulties in transitions to new protocol some historical examples of difficulties in transitions to new protocol
features. <xref target="use-it" format="default"/> argues that ossified protoco ls are more difficult to features. <xref target="use-it" format="default"/> argues that ossified protoco ls are more difficult to
update and describes how successful protocols make frequent use of new update and describes how successful protocols make frequent use of new
extensions and code-points. <xref target="other" format="default"/> outlines se veral additional strategies extensions and code points. <xref target="other" format="default"/> outlines se veral additional strategies
that might aid in ensuring that protocol changes remain possible over time.</t> that might aid in ensuring that protocol changes remain possible over time.</t>
<t>The experience that informs this document is predominantly at "higher" layers of <t>The experience that informs this document is predominantly at "higher" layers of
the network stack, in protocols with limited numbers of participants. Though the network stack, in protocols with limited numbers of participants. Though
similar issues are present in many protocols that operate at scale, the similar issues are present in many protocols that operate at scale, the
tradeoffs involved with applying some of the suggested techniques can be more trade-offs involved with applying some of the suggested techniques can be more
complex when there are many participants, such as at the network layer or in complex when there are many participants, such as at the network layer or in
routing systems.</t> routing systems.</t>
</section> </section>
<section anchor="implementations" numbered="true" toc="default"> <section anchor="implementations" numbered="true" toc="default">
<name>Imperfect Implementations Limit Protocol Evolution</name> <name>Imperfect Implementations Limit Protocol Evolution</name>
<t>It can be extremely difficult to deploy a change to a protocol if <t>It can be extremely difficult to deploy a change to a protocol if
implementations with which the new deployment needs to interoperate do not implementations with which the new deployment needs to interoperate do
operate predictably. Variation in how new codepoints or extensions are handled not operate predictably. Variation in how new code points or extensions
can be the result of bugs in implementation or specifications. Unpredictability are handled can be the result of bugs in implementation or
can manifest as abrupt termination of sessions, errors, crashes, or specifications.
disappearances of endpoints and timeouts.</t>
<t>The risk of interoperability problems can in turn make it infeasible to Unpredictability can manifest as errors, crashes, timeouts, abrupt
deploy certain protocol changes. If deploying a new codepoint or extension termination of sessions, or disappearances of endpoints.
makes an implementation less reliable than others, even if only in rare cases,
it is far less likely that implementations will adopt the change.</t> </t>
<t>Deploying a change to a protocol could require implementations to fix a <t>The risk of interoperability problems can in turn make it infeasible
substantial proportion of the bugs that the change exposes. This can to deploy certain protocol changes. If deploying a new code point or
involve a difficult process that includes identifying the cause of extension makes an implementation less reliable than others, even if
these errors, finding the responsible implementation(s), coordinating a only in rare cases, it is far less likely that implementations will
bug fix and release plan, contacting users and/or the operator of affected adopt the change.</t>
services, and waiting for the fix to be deployed.</t> <t>Deploying a change to a protocol could require implementations to fix
<t>Given the effort involved in fixing problems, the existence of these so a substantial proportion of the bugs that the change exposes. This can
rts of involve a difficult process that includes identifying the cause of these
bugs can outright prevent the deployment of some types of protocol changes, errors, finding the responsible implementation(s), coordinating a bug
especially for protocols involving multiple parties or that are considered fix and release plan, contacting users and/or the operator of affected
critical infrastructure (e.g., IP, BGP, DNS, or TLS). It could even be services, and waiting for the fix to be deployed.</t>
necessary to come up with a new protocol design that uses a different method to <t>Given the effort involved in fixing problems, the existence of these
achieve the same result.</t> sorts of bugs can outright prevent the deployment of some types of
protocol changes, especially for protocols involving multiple parties or
that are considered critical infrastructure (e.g., IP, BGP, DNS, or
TLS). It could even be necessary to come up with a new protocol design
that uses a different method to achieve the same result.</t>
<t>This document only addresses cases where extensions are not deliberatel y <t>This document only addresses cases where extensions are not deliberatel y
blocked. Some deployments or implementations apply policies that explicitly blocked. Some deployments or implementations apply policies that explicitly
prohibit the use of unknown capabilities. This is especially true of functions prohibit the use of unknown capabilities. This is especially true of functions
that seek to make security guarantees, like firewalls.</t> that seek to make security guarantees, like firewalls.</t>
<t>The set of interoperable features in a protocol is often the subset of its <t>The set of interoperable features in a protocol is often the subset of its
features that have some value to those implementing and deploying the protocol. features that have some value to those implementing and deploying the protocol.
It is not always the case that future extensibility is in that set.</t> It is not always the case that future extensibility is in that set.</t>
<section anchor="not-good-enough" numbered="true" toc="default"> <section anchor="not-good-enough" numbered="true" toc="default">
<name>Good Protocol Design is Not Itself Sufficient</name> <name>Good Protocol Design Is Not Itself Sufficient</name>
<t>It is often argued that the careful design of a protocol extension po <t>It is often argued that the careful design of a protocol extension
int or point or version-negotiation capability is critical to the freedom
version negotiation capability is critical to the freedom that it ultimately that it ultimately offers.</t>
offers.</t> <t>RFC 6709 <xref target="RFC6709" format="default"/> contains a great
<t>RFC 6709 <xref target="EXTENSIBILITY" format="default"/> contains a g deal of well-considered advice on designing for extensions. It
reat deal of well-considered includes the following advice:</t>
advice on designing for extension. It includes the following advice:</t>
<ul empty="true"> <blockquote>
<li> <t>
<t>This means that, to be useful, a protocol version-negotiation mec This means that, to be useful, a protocol version-negotiation mechanism
hanism
should be simple enough that it can reasonably be assumed that all the should be simple enough that it can reasonably be assumed that all the
implementers of the first protocol version at least managed to implement the implementers of the first protocol version at least managed to implement the
version-negotiation mechanism correctly.</t> version-negotiation mechanism correctly.
</li> </t>
</ul> </blockquote>
<t>There are a number of protocols for which this has proven to be insuf
ficient in <t>There are a number of protocols for which this has proven to be insufficient
in
practice. These protocols have imperfect implementations of these mechanisms. practice. These protocols have imperfect implementations of these mechanisms.
Mechanisms that aren't used are the ones that fail most often. The same Mechanisms that aren't used are the ones that fail most often. The same
paragraph from RFC 6709 acknowledges the existence of this problem, but does not paragraph from RFC 6709 acknowledges the existence of this problem but does not
offer any remedy:</t> offer any remedy:</t>
<ul empty="true">
<li> <blockquote>
<t>The nature of protocol version-negotiation mechanisms is that, by <t>
definition, The nature of protocol version-negotiation mechanisms is that, by
they don't get widespread real-world testing until <em>after</em> the base pro definition, they don't get widespread real-world testing until
tocol <strong>after</strong> the base protocol has been deployed for a while, and
has been deployed for a while, and its deficiencies have become evident.</t> its
</li> deficiencies have become evident.
</ul> </t>
</blockquote>
<t>Indeed, basic interoperability is considered critical early in the de ployment of <t>Indeed, basic interoperability is considered critical early in the de ployment of
a protocol. A desire to deploy can result in early focus on a reduced feature a protocol. A desire to deploy can result in early focus on a reduced feature
set, which could result in deferring implementation of version negotiation and set, which could result in deferring implementation of version-negotiation and
extension mechanisms. This leads to these mechanisms being particularly extension mechanisms. This leads to these mechanisms being particularly
affected by this problem.</t> affected by this problem.</t>
</section> </section>
<section anchor="disuse" numbered="true" toc="default"> <section anchor="disuse" numbered="true" toc="default">
<name>Disuse Can Hide Problems</name> <name>Disuse Can Hide Problems</name>
<t>There are many examples of extension points in protocols that have be en either <t>There are many examples of extension points in protocols that have be en either
completely unused, or their use was so infrequent that they could no longer be completely unused or their use was so infrequent that they could no longer be
relied upon to function correctly.</t> relied upon to function correctly.</t>
<t><xref target="examples" format="default"/> includes examples of disus e in a number of widely deployed Internet <t><xref target="examples" format="default"/> includes examples of disus e in a number of widely deployed Internet
protocols.</t> protocols.</t>
<t>Even where extension points have multiple valid values, if the set of <t>Even where extension points have multiple valid values, if the set
permitted of permitted values does not change over time, there is still a risk
values does not change over time, there is still a risk that new values are not that new values are not tolerated by existing implementations. If the
tolerated by existing implementations. If the set of values for a particular set of values for a particular field of a protocol or the order in which
field or the order in which these values appear of a these
protocol remains fixed over a long period, some implementations might not values appear remains fixed over a long period, some
correctly handle a new value when it is introduced. For example, implementations might not correctly handle a new value when it is
implementations of TLS broke when new values of the signature_algorithms introduced. For example, implementations of TLS broke when new values
extension were introduced.</t> of the signature_algorithms extension were introduced.</t>
</section> </section>
<section anchor="middleboxes" numbered="true" toc="default"> <section anchor="middleboxes" numbered="true" toc="default">
<name>Multi-Party Interactions and Middleboxes</name> <name>Multi-party Interactions and Middleboxes</name>
<t>One of the key challenges in deploying new features is ensuring compa tibility <t>One of the key challenges in deploying new features is ensuring compa tibility
with all actors that could be involved in the protocol. Even the most with all actors that could be involved in the protocol. Even the most
superficially simple protocols can often involve more actors than is immediately superficially simple protocols can often involve more actors than is immediately
apparent.</t> apparent.</t>
<t>The design of extension points needs to consider what actions middleb oxes <t>The design of extension points needs to consider what actions middleb oxes
might take in response to a protocol change, as well as the effect those actions might take in response to a protocol change as well as the effect those actions
could have on the operation of the protocol.</t> could have on the operation of the protocol.</t>
<t>Deployments of protocol extensions also need to consider the impact <t>Deployments of protocol extensions also need to consider the impact
of the changes on entities beyond protocol participants and middleboxes. of the changes on entities beyond protocol participants and middleboxes.
Protocol changes can affect the behavior of applications or systems Protocol changes can affect the behavior of applications or systems
that don't directly interact with the protocol, such as when a protocol that don't directly interact with the protocol, such as when a protocol
change modifies the formatting of data delivered to an application.</t> change modifies the formatting of data delivered to an application.</t>
</section> </section>
</section> </section>
<section anchor="use-it" numbered="true" toc="default"> <section anchor="use-it" numbered="true" toc="default">
<name>Active Use</name> <name>Active Use</name>
skipping to change at line 175 skipping to change at line 180
could have on the operation of the protocol.</t> could have on the operation of the protocol.</t>
<t>Deployments of protocol extensions also need to consider the impact <t>Deployments of protocol extensions also need to consider the impact
of the changes on entities beyond protocol participants and middleboxes. of the changes on entities beyond protocol participants and middleboxes.
Protocol changes can affect the behavior of applications or systems Protocol changes can affect the behavior of applications or systems
that don't directly interact with the protocol, such as when a protocol that don't directly interact with the protocol, such as when a protocol
change modifies the formatting of data delivered to an application.</t> change modifies the formatting of data delivered to an application.</t>
</section> </section>
</section> </section>
<section anchor="use-it" numbered="true" toc="default"> <section anchor="use-it" numbered="true" toc="default">
<name>Active Use</name> <name>Active Use</name>
<t>The design of a protocol for extensibility and eventual replacement <t>The design of a protocol for extensibility and eventual replacement
<xref target="EXTENSIBILITY" format="default"/> does not guarantee the ability t <xref target="RFC6709" format="default"/> does not guarantee the ability
o exercise those options. to exercise those options. The set of features that enable future
The set of features that enable future evolution need to be interoperable in the evolution need to be interoperable in the first implementations and
first implementations and deployments of the protocol. Implementation of deployments of the protocol. Implementation of mechanisms that support
mechanisms that support evolution is necessary to ensure that they remain evolution is necessary to ensure that they remain available for new
available for new uses, and history has shown this occurs almost exclusively uses, and history has shown this occurs almost exclusively through
through active mechanism use.</t> active mechanism use.</t>
<t>Only by using the extension capabilities of a protocol is the availabil <t>Only by using the extension capabilities of a protocol is the
ity of that availability of that capability assured. "Using" here includes
capability assured. "Using" here includes specifying, implementing, and specifying, implementing, and deploying capabilities that rely on the
deploying capabilities that rely on the extension capability. Protocols that extension capability. Protocols that fail to use a mechanism, or a
fail to use a mechanism, or a protocol that only rarely uses a mechanism, could protocol that only rarely uses a mechanism, could lead to that mechanism
lead to that mechanism being unreliable.</t> being unreliable.</t>
<t>Implementations that routinely see new values are more likely to correc <t>Implementations that routinely see new values are more likely to
tly correctly handle new values. More frequent changes will improve the
handle new values. More frequent changes will improve the likelihood that likelihood that incorrect handling or intolerance is discovered and
incorrect handling or intolerance is discovered and rectified. The longer an rectified. The longer an intolerant implementation is deployed, the
intolerant implementation is deployed, the more difficult it is to correct.</t> more difficult it is to correct.</t>
<t>Protocols that routinely add new extensions and code points rarely have <t>Protocols that routinely add new extensions and code points rarely
trouble have trouble adding additional ones especially when the handling of new
adding additional ones, especially when the handling of new versions or versions or extensions are well defined. The definition of mechanisms
extensions are well defined. The definition of mechanisms alone is alone is insufficient; it is the assured implementation and active use
insufficient; it is the assured implementation and active use of those of those mechanisms that determines their availability.</t>
mechanisms that determines their availability.</t> <t>What constitutes "active use" can depend greatly on the environment
<t>What constitutes "active use" can depend greatly on the environment in in which a protocol is deployed. The frequency of changes necessary to
which a safeguard some mechanisms might be slow enough to attract ossification
protocol is deployed. The frequency of changes necessary to safeguard some in another protocol deployment, while being excessive in others.</t>
mechanisms might be slow enough to attract ossification in another protocol
deployment, while being excessive in others.</t>
<section anchor="need-it" numbered="true" toc="default"> <section anchor="need-it" numbered="true" toc="default">
<name>Dependency is Better</name> <name>Dependency Is Better</name>
<t>The easiest way to guarantee that a protocol mechanism is used is to <t>The easiest way to guarantee that a protocol mechanism is used is
make the to make the handling of it critical to an endpoint participating in
handling of it critical to an endpoint participating in that protocol. This that protocol. This means that implementations must rely on both the
means that implementations must rely on both the existence of extension existence of extension mechanisms and their continued, repeated
mechanisms and their continued, repeated expansion over time.</t> expansion over time.</t>
<t>For example, the message format in SMTP relies on header fields for m ost of its <t>For example, the message format in SMTP relies on header fields for m ost of its
functions, including the most basic delivery functions. A deployment of SMTP functions, including the most basic delivery functions. A deployment of SMTP
cannot avoid including an implementation of header field handling. In addition cannot avoid including an implementation of header field handling. In addition
to this, the regularity with which new header fields are defined and used to this, the regularity with which new header fields are defined and used
ensures that deployments frequently encounter header fields that they do not yet ensures that deployments frequently encounter header fields that they do not yet
(and may never) understand. An SMTP implementation therefore needs to be able (and may never) understand. An SMTP implementation therefore needs to be able
to both process header fields that it understands and ignore those that it does to both process header fields that it understands and ignore those that it does
not.</t> not.</t>
<t>In this way, implementing the extensibility mechanism is not merely m andated by <t>In this way, implementing the extensibility mechanism is not merely m andated by
the specification, it is crucial to the functioning of a protocol deployment. the specification, it is crucial to the functioning of a protocol deployment.
skipping to change at line 227 skipping to change at line 237
would quickly become apparent.</t> would quickly become apparent.</t>
<t>Caution is advised to avoid assuming that building a dependency on an extension <t>Caution is advised to avoid assuming that building a dependency on an extension
mechanism is sufficient to ensure availability of that mechanism in the long mechanism is sufficient to ensure availability of that mechanism in the long
term. If the set of possible uses is narrowly constrained and deployments do term. If the set of possible uses is narrowly constrained and deployments do
not change over time, implementations might not see new variations or assume a not change over time, implementations might not see new variations or assume a
narrower interpretation of what is possible. Those implementations might still narrower interpretation of what is possible. Those implementations might still
exhibit errors when presented with new variations.</t> exhibit errors when presented with new variations.</t>
</section> </section>
<section anchor="version-negotiation" numbered="true" toc="default"> <section anchor="version-negotiation" numbered="true" toc="default">
<name>Version Negotiation</name> <name>Version Negotiation</name>
<t>As noted in <xref target="not-good-enough" format="default"/>, protoc <t>As noted in <xref target="not-good-enough" format="default"/>,
ols that provide version negotiation protocols that provide version-negotiation mechanisms might not be
mechanisms might not be able to test that feature until a new version is able to test that feature until a new version is deployed. One
deployed. One relatively successful design approach has been to use the relatively successful design approach has been to use the protocol
protocol selection mechanisms built into a lower-layer protocol to select the selection mechanisms built into a lower-layer protocol to select the
protocol. This could allow a version negotiation mechanism to benefit from protocol. This could allow a version-negotiation mechanism to benefit
active use of the extension point by other protocols.</t> from active use of the extension point by other protocols.</t>
<t>For instance, all published versions of IP contain a version number a <t>For instance, all published versions of IP contain a version number
s the four as the four high bits of the first header byte. However, version
high bits of the first header byte. However, version selection using this selection using this field proved to be unsuccessful. Ultimately,
field proved to be unsuccessful. Ultimately, successful deployment of IPv6 successful deployment of IPv6 over Ethernet <xref target="RFC2464"
over Ethernet <xref target="RFC2464" format="default"/> required a different Eth format="default"/> required a different EtherType from IPv4. This
erType from IPv4. This change took advantage of the already diverse usage of EtherType.</t>
change took advantage of the already-diverse usage of EtherType.</t> <t>Other examples of this style of design include Application-Layer
<t>Other examples of this style of design include Application-Layer Prot Protocol Negotiation (<xref target="RFC7301" format="default"/>) and
ocol HTTP content negotiation (<xref section="12" sectionFormat="of"
Negotiation (<xref target="ALPN" format="default"/>) and HTTP content negotiatio target="I-D.ietf-httpbis-semantics" format="default"/>).</t>
n (<xref section="12" sectionFormat="of" target="HTTP" format="default"/>).</t> <t>This technique relies on the code point being usable. For instance,
<t>This technique relies on the codepoint being usable. For instance, t the IP protocol number is known to be unreliable and therefore not
he IP suitable <xref target="NEW-PROTOCOLS" format="default"/>.</t>
protocol number is known to be unreliable and therefore not suitable
<xref target="NEW-PROTOCOLS" format="default"/>.</t>
</section> </section>
<section anchor="grease" numbered="true" toc="default"> <section anchor="grease" numbered="true" toc="default">
<name>Falsifying Active Use</name> <name>Falsifying Active Use</name>
<t>"Grease" was originally defined for TLS <xref target="GREASE" format=
"default"/>, but has been <t>"Grease" was originally defined for TLS <xref target="RFC8701"
adopted by other protocols, such as QUIC <xref target="QUIC" format="default"/>. format="default"/> but has been adopted by other protocols such as
Grease identifies QUIC <xref target="RFC9000" format="default"/>. Grease identifies
lack of use as an issue (protocol mechanisms "rusting" shut) and proposes lack of use as an issue (protocol mechanisms "rusting" shut) and
reserving values for extensions that have no semantic value attached.</t> proposes reserving values for extensions that have no semantic value
<t>The design in <xref target="GREASE" format="default"/> is aimed at th attached.</t>
e style of negotiation most used in TLS, <t>The design in <xref target="RFC8701" format="default"/> is aimed at
where one endpoint offers a set of options and the other chooses the one that it the style of negotiation most used in TLS, where one endpoint offers a
most prefers from those that it supports. An endpoint that uses grease randomly set of options and the other chooses the one that it most prefers from
offers options - usually just one - from a set of reserved values. These values those that it supports. An endpoint that uses grease randomly offers
are guaranteed to never be assigned real meaning, so its peer will never have options, usually just one, from a set of reserved values. These
cause to genuinely select one of these values.</t> values are guaranteed to never be assigned real meaning, so its peer
<t>More generally, greasing is used to refer to any attempt to exercise will never have cause to genuinely select one of these values.</t>
extension <t>More generally, greasing is used to refer to any attempt to
points without changing endpoint behavior, other than to encourage participants exercise extension points without changing endpoint behavior other
to tolerate new or varying values of protocol elements.</t> than to encourage participants to tolerate new or varying values of
<t>The principle that grease operates on is that an implementation that protocol elements.</t>
is
regularly exposed to unknown values is less likely to be intolerant of new <t>The principle that grease operates on is that an implementation
values when they appear. This depends largely on the assumption that the that is regularly exposed to unknown values is less likely to be
difficulty of implementing the extension mechanism correctly is as easy or intolerant of new values when they appear. This depends largely on
easier than implementing code to identify and filter out reserved values. the assumption that the difficulty of implementing the extension
Reserving random or unevenly distributed values for this purpose is thought to mechanism correctly is as easy or easier than implementing code to
further discourage special treatment.</t> identify and filter out reserved values. Reserving random or unevenly
<t>Without reserved greasing codepoints, an implementation can use code distributed values for this purpose is thought to further discourage
points from special treatment.</t>
spaces used for private or experimental use if such a range exists. In addition <t>Without reserved greasing code points, an implementation can use
to the risk of triggering participation in an unwanted experiment, this can be code points from spaces used for private or experimental use if such a
less effective. Incorrect implementations might still be able to identify these range exists. In addition to the risk of triggering participation in
code points and ignore them.</t> an unwanted experiment, this can be less effective. Incorrect
<t>In addition to advertising bogus capabilities, an endpoint might also implementations might still be able to identify these code points and
selectively disable non-critical protocol elements to test the ability of peers ignore them.</t>
to handle the absence of certain capabilities.</t> <t>In addition to advertising bogus capabilities, an endpoint might
<t>This style of defensive design is limited because it is only superfic also selectively disable noncritical protocol elements to test the
ial. As ability of peers to handle the absence of certain capabilities.</t>
greasing only mimics active use of an extension point, it only exercises a small <t>This style of defensive design is limited because it is only
part of the mechanisms that support extensibility. More critically, it does not superficial. As greasing only mimics active use of an extension
easily translate to all forms of extension points. For instance, HMSV point, it only exercises a small part of the mechanisms that support
negotiation cannot be greased in this fashion. Other techniques might be extensibility. More critically, it does not easily translate to all
necessary for protocols that don't rely on the particular style of exchange that forms of extension points. For instance, highest mutually supported
is predominant in TLS.</t> version (HMSV) negotiation cannot be greased in this fashion. Other
techniques might be necessary for protocols that don't rely on the
particular style of exchange that is predominant in TLS.</t>
<t>Grease is deployed with the intent of quickly revealing errors in imp lementing <t>Grease is deployed with the intent of quickly revealing errors in imp lementing
the mechanisms it safeguards. Though it has been effective at revealing the mechanisms it safeguards. Though it has been effective at revealing
problems in some cases with TLS, the efficacy of greasing isn't proven more problems in some cases with TLS, the efficacy of greasing isn't proven more
generally. Where implementations are able to tolerate a non-zero error rate in generally. Where implementations are able to tolerate a non-zero error rate in
their operation, greasing offers a potential option for safeguarding future their operation, greasing offers a potential option for safeguarding future
extensibility. However, this relies on there being a sufficient proportion of extensibility. However, this relies on there being a sufficient proportion of
participants that are willing to invest the effort and tolerate the risk of participants that are willing to invest the effort and tolerate the risk of
interoperability failures.</t> interoperability failures.</t>
</section> </section>
<section anchor="ex-active" numbered="true" toc="default"> <section anchor="ex-active" numbered="true" toc="default">
<name>Examples of Active Use</name> <name>Examples of Active Use</name>
<t>Header fields in email <xref target="SMTP" format="default"/>, HTTP < <t>Header fields in email <xref target="RFC5321" format="default"/>,
xref target="HTTP" format="default"/> and SIP HTTP <xref target="I-D.ietf-httpbis-semantics" format="default"/>, and S
<xref target="SIP" format="default"/> all derive from the same basic design, whi IP <xref
ch amounts to a list target="RFC3261" format="default"/> all derive from the same basic
name/value pairs. There is no evidence of significant barriers to deploying design, which amounts to a list of name/value pairs. There is no
header fields with new names and semantics in email and HTTP as clients and evidence of significant barriers to deploying header fields with new
servers generally ignore headers they do not understand or need. The widespread names and semantics in email and HTTP as clients and servers generally
deployment of SIP B2BUAs, which generally do not ignore unknown fields, means ignore headers they do not understand or need. The widespread
that new SIP header fields do not reliably reach peers. This does not deployment of SIP back-to-back user agents (B2BUAs), which generally
necessarily cause interoperability issues in SIP but rather causes features to do not ignore unknown fields, means that new SIP header fields do not
remain unavailable until the B2BUA is updated. All three protocols are still reliably reach peers. This does not necessarily cause
able to deploy new features reliably, but SIP features are deployed more slowly interoperability issues in SIP but rather causes features to remain
due to the larger number of active participants that need to support new unavailable until the B2BUA is updated. All three protocols are still
features.</t> able to deploy new features reliably, but SIP features are deployed
more slowly due to the larger number of active participants that need
to support new features.</t>
<t>As another example, the attribute-value pairs (AVPs) in Diameter <t>As another example, the attribute-value pairs (AVPs) in Diameter
<xref target="DIAMETER" format="default"/> are fundamental to the design of the protocol. Any use of <xref target="RFC6733" format="default"/> are fundamental to the design of the p rotocol. Any use of
Diameter requires exercising the ability to add new AVPs. This is routinely Diameter requires exercising the ability to add new AVPs. This is routinely
done without fear that the new feature might not be successfully deployed.</t> done without fear that the new feature might not be successfully deployed.</t>
<t>These examples show extension points that are heavily used are also b eing <t>These examples show extension points that are heavily used are also b eing
relatively unaffected by deployment issues preventing addition of new values relatively unaffected by deployment issues preventing addition of new values
for new use cases.</t> for new use cases.</t>
<t>These examples show that a good design is not required for success. On the <t>These examples show that a good design is not required for success. On the
contrary, success is often despite shortcomings in the design. For instance, contrary, success is often despite shortcomings in the design. For instance,
the shortcomings of HTTP header fields are significant enough that there are the shortcomings of HTTP header fields are significant enough that there are
ongoing efforts to improve the syntax <xref target="HTTP-HEADERS" format="defaul t"/>.</t> ongoing efforts to improve the syntax <xref target="RFC8941" format="default"/>. </t>
</section> </section>
<section anchor="restoring-active-use" numbered="true" toc="default"> <section anchor="restoring-active-use" numbered="true" toc="default">
<name>Restoring Active Use</name> <name>Restoring Active Use</name>
<t>With enough effort, active use can be used to restore capabililities. <t>With enough effort, active use can be used to restore capabilities.</
</t> t>
<t>EDNS <xref target="EDNS" format="default"/> was defined to provide ex <t>Extension Mechanisms for DNS (<xref target="RFC6891"
tensibility in DNS. Intolerance format="default"/>) was defined to provide extensibility in DNS.
of the extension in DNS servers resulted in a fallback method being widely Intolerance of the extension in DNS servers resulted in a fallback
deployed (see <xref section="6.2.2" sectionFormat="of" target="EDNS" format="def method being widely deployed (see <xref section="6.2.2"
ault"/>). This fallback resulted in EDNS being sectionFormat="of" target="RFC6891" format="default"/>). This
disabled for affected servers. Over time, greater support for EDNS and fallback resulted in EDNS being disabled for affected servers. Over
increased reliance on it for different features motivated a flag day time, greater support for EDNS and increased reliance on it for
<xref target="DNSFLAGDAY" format="default"/> where the workaround was removed.</ different features motivated a flag day <xref target="DNSFLAGDAY"
t> format="default"/> where the workaround was removed.</t>
<t>The EDNS example shows that effort can be used to restore capabilitie s. This is <t>The EDNS example shows that effort can be used to restore capabilitie s. This is
in part because EDNS was actively used with most resolvers and servers. It was in part because EDNS was actively used with most resolvers and servers. It was
therefore possible to force a change to ensure that extension capabilities would therefore possible to force a change to ensure that extension capabilities would
always be available. However, this required an enormous coordination effort. A always be available. However, this required an enormous coordination effort. A
small number of incompatible servers and the names they serve also became small number of incompatible servers and the names they serve also became
inaccessible to most clients.</t> inaccessible to most clients.</t>
</section> </section>
</section> </section>
<section anchor="other" numbered="true" toc="default"> <section anchor="other" numbered="true" toc="default">
<name>Complementary Techniques</name> <name>Complementary Techniques</name>
<t>The protections to protocol evolution that come from <xref target="use- it" format="default">active use</xref> can <t>The protections to protocol evolution that come from <xref target="use- it" format="default">active use</xref> can
be improved through the use of other defensive techniques. The techniques listed be improved through the use of other defensive techniques. The techniques listed
here might not prevent ossification on their own, but can make active use more here might not prevent ossification on their own, but they can make active use m ore
effective.</t> effective.</t>
<section anchor="fewer-extension-points" numbered="true" toc="default">
<section anchor="fewer-extension-points" numbered="true" toc="default">
<name>Fewer Extension Points</name> <name>Fewer Extension Points</name>
<t>A successful protocol will include many potential types of extension. <t>A successful protocol will include many potential types of
Designing extensions. Designing multiple types of extension mechanisms, each
multiple types of extension mechanism, each suited to a specific purpose, might suited to a specific purpose, might leave some extension points less
leave some extension points less heavily used than others.</t> heavily used than others.</t>
<t>Disuse of a specialized extension point might render it unusable. In <t>Disuse of a specialized extension point might render it unusable.
contrast, In contrast, having a smaller number of extension points with wide
having a smaller number of extension points with wide applicability could applicability could improve the use of those extension points. Use of
improve the use of those extension points. Use of a shared extension point for a shared extension point for any purpose can protect rarer or more
any purpose can protect rarer or more specialized uses.</t> specialized uses.</t>
<t>Both extensions and core protocol elements use the same extension poi <t>Both extensions and core protocol elements use the same extension
nts in points in protocols like HTTP <xref target="I-D.ietf-httpbis-semantics"
protocols like HTTP <xref target="HTTP" format="default"/> and DIAMETER <xref ta format="default"/> and DIAMETER <xref target="RFC6733"
rget="DIAMETER" format="default"/>; see <xref target="ex-active" format="default format="default"/>; see <xref target="ex-active"
"/>.</t> format="default"/>.</t>
</section> </section>
<section anchor="invariants" numbered="true" toc="default"> <section anchor="invariants" numbered="true" toc="default">
<name>Invariants</name> <name>Invariants</name>
<t>Documenting aspects of the protocol that cannot or will not change as extensions <t>Documenting aspects of the protocol that cannot or will not change as extensions
or new versions are added can be a useful exercise. <xref section="2.2" sectionF ormat="of" target="RFC5704" format="default"/> or new versions are added can be a useful exercise. <xref section="2.2" sectionF ormat="of" target="RFC5704" format="default"/>
defines invariants as:</t> defines invariants as:</t>
<ul empty="true"> <blockquote>
<li> <t>
<t>Invariants are core properties that are consistent across the net Invariants are core properties that are consistent across the network and
work and do do not change over extremely long time-scales.
not change over extremely long time-scales.</t> </t>
</li> </blockquote>
</ul> <t>Understanding what aspects of a protocol are invariant can help guide the
<t>Understanding what aspects of a protocol are invariant can help guide
the
process of identifying those parts of the protocol that might change. process of identifying those parts of the protocol that might change.
<xref target="QUIC-INVARIANTS" format="default"/> and <xref section="9.3" sectio nFormat="of" target="TLS13" format="default"/> are both examples of <xref target="RFC8999" format="default"/> and <xref section="9.3" sectionFormat= "of" target="RFC8446" format="default"/> are both examples of
documented invariants.</t> documented invariants.</t>
<t>As a means of protecting extensibility, a declaration of protocol inv <t>As a means of protecting extensibility, a declaration of protocol
ariants is invariants is useful only to the extent that protocol participants are
useful only to the extent that protocol participants are willing to allow new willing to allow new uses for the protocol. A protocol that declares
uses for the protocol. A protocol that declares protocol invariants relies on protocol invariants relies on implementations understanding and
implementations understanding and respecting those invariants. If active use is respecting those invariants. If active use is not possible for all
not non-invariant parts of the protocol, greasing (<xref target="grease"
possible for all non-invariant parts of the protocol, greasing (<xref target="gr format="default"/>) might be used to improve the chance that
ease" format="default"/>) might be invariants are respected.</t>
used to improve the chance that invariants are respected.</t> <t>Protocol invariants need to be clearly and concisely documented.
<t>Protocol invariants need to be clearly and concisely documented. Inc Including examples of aspects of the protocol that are not invariant,
luding such as <xref target="RFC8999" section="A" format="default"/>, can be
examples of aspects of the protocol that are not invariant, such as <xref sectio used to clarify intent.</t>
n="A" sectionFormat="of" target="QUIC-INVARIANTS" format="default"/>, can be use
d to clarify intent.</t>
</section> </section>
<section anchor="limiting-participation" numbered="true" toc="default"> <section anchor="limiting-participation" numbered="true" toc="default">
<name>Limiting Participation</name> <name>Limiting Participation</name>
<t>Reducing the number of entities that can participate in a protocol or <t>Reducing the number of entities that can participate in a protocol
limiting or limiting the extent of participation can reduce the number of
the extent of participation can reduce the number of entities that might affect entities that might affect extensibility. Using TLS or other
extensibility. Using TLS or other cryptographic tools can therefore reduce the cryptographic tools can therefore reduce the number of entities that
number of entities that can influence whether new features are usable.</t> can influence whether new features are usable.</t>
<t><xref target="PATH-SIGNALS" format="default"/> also recommends the us <t><xref target="RFC8558" format="default"/> also recommends the use
e of encryption and integrity of encryption and integrity protection to limit participation. For
protection to limit participation. For example, encryption is used by the QUIC example, encryption is used by the QUIC protocol <xref
protocol <xref target="QUIC" format="default"/> to limit the information that is target="RFC9000" format="default"/> to limit the information that is
available to available to middleboxes and integrity protection prevents
middleboxes and integrity protection prevents modification.</t> modification.</t>
</section> </section>
<section anchor="effective-feedback" numbered="true" toc="default"> <section anchor="effective-feedback" numbered="true" toc="default">
<name>Effective Feedback</name> <name>Effective Feedback</name>
<t>While not a direct means of protecting extensibility mechanisms, feed <t>While not a direct means of protecting extensibility mechanisms,
back feedback systems can be important to discovering problems.</t>
systems can be important to discovering problems.</t> <t>The visibility of errors is critical to the success of techniques lik
<t>Visibility of errors is critical to the success of techniques like gr e
ease (see grease (see <xref target="grease" format="default"/>). The grease
<xref target="grease" format="default"/>). The grease design is most effective design is most effective if a deployment has a means of detecting and
if a deployment has a means of reporting errors. Ignoring errors could allow problems to become
detecting and reporting errors. Ignoring errors could allow problems to become entrenched.</t>
entrenched.</t> <t>Feedback on errors is more important during the development and
<t>Feedback on errors is more important during the development and early early deployment of a change. It might also be helpful to disable
deployment automatic error recovery methods during development.</t>
of a change. It might also be helpful to disable automatic error recovery <t>Automated feedback systems are important for automated systems, or
methods during development.</t> where error recovery is also automated. For instance, connection
<t>Automated feedback systems are important for automated systems, or wh failures with HTTP alternative services <xref target="RFC7838"
ere error format="default"/> are not permitted to affect the outcome of
recovery is also automated. For instance, connection failures with HTTP transactions. An automated feedback system for capturing failures in
alternative services <xref target="ALT-SVC" format="default"/> are not permitted alternative services is therefore necessary for failures to be
to affect the detected.</t>
outcome of transactions. An automated feedback system for capturing failures in <t>How errors are gathered and reported will depend greatly on the
alternative services is therefore necessary for failures to be detected.</t> nature of the protocol deployment and the entity that receives the
<t>How errors are gathered and reported will depend greatly on the natur report. For instance, end users, developers, and network operations
e of the each have different requirements for how error reports are created,
protocol deployment and the entity that receives the report. For instance, end managed, and acted upon.</t>
users, developers, and network operations each have different requirements for <t>Automated delivery of error reports can be critical for rectifying
how error reports are created, managed, and acted upon.</t> deployment errors as early as possible, as seen in <xref
<t>Automated delivery of error reports can be critical for rectifying de target="RFC7489" format="default"/> and <xref target="RFC8460"
ployment format="default"/>.</t>
errors as early as possible, such as seen in <xref target="DMARC" format="defaul
t"/> and
<xref target="SMTP-TLS-Reporting" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Many of the problems identified in this document are not the result of <t>Many of the problems identified in this document are not the result
deliberate actions by an adversary, but more the result of mistakes, decisions of deliberate actions by an adversary but more the result of mistakes,
made without sufficient context, or simple neglect. Problems therefore not the decisions made without sufficient context, or simple neglect, i.e.,
result of opposition by an adversary. In response, the recommended measures problems therefore not the result of opposition by an adversary. In
generally assume that other protocol participants will not take deliberate response, the recommended measures generally assume that other protocol
action to prevent protocol evolution.</t> participants will not take deliberate action to prevent protocol
evolution.</t>
<t>The use of cryptographic techniques to exclude potential participants i s the <t>The use of cryptographic techniques to exclude potential participants i s the
only strong measure that the document recommends. However, authorized protocol only strong measure that the document recommends. However, authorized protocol
peers are most often responsible for the identified problems, which can mean peers are most often responsible for the identified problems, which can mean
that cryptography is insufficient to exclude them.</t> that cryptography is insufficient to exclude them.</t>
<t>The ability to design, implement, and deploy new protocol mechanisms ca n be <t>The ability to design, implement, and deploy new protocol mechanisms ca n be
critical to security. In particular, it is important to be able to replace critical to security. In particular, it is important to be able to replace
cryptographic algorithms over time <xref target="AGILITY" format="default"/>. F cryptographic algorithms over time <xref target="RFC7696" format="default"/>. F
or example, or example,
preparing for replacement of weak hash algorithms was made more difficult preparing for the replacement of weak hash algorithms was made more difficult
through misuse <xref target="HASH" format="default"/>.</t> through misuse <xref target="HASH" format="default"/>.</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no request of IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-httpbis-semantics" to="HTTP"/>
<displayreference target="I-D.ietf-httpbis-messaging" to="HTTP11"/>
<displayreference target="RFC5218" to="SUCCESS"/>
<displayreference target="RFC8170" to="TRANSITIONS"/>
<displayreference target="RFC6709" to="EXTENSIBILITY"/>
<displayreference target="RFC7301" to="ALPN"/>
<displayreference target="RFC8701" to="GREASE"/>
<displayreference target="RFC9000" to="QUIC"/>
<displayreference target="RFC5321" to="SMTP"/>
<displayreference target="RFC3261" to="SIP"/>
<displayreference target="RFC6733" to="DIAMETER"/>
<displayreference target="RFC8941" to="HTTP-HEADERS"/>
<displayreference target="RFC6891" to="EDNS"/>
<displayreference target="RFC8999" to="QUIC-INVARIANTS"/>
<displayreference target="RFC8558" to="PATH-SIGNALS"/>
<displayreference target="RFC7838" to="ALT-SVC"/>
<displayreference target="RFC7489" to="DMARC"/>
<displayreference target="RFC8460" to="SMTP-TLS-REPORTING"/>
<displayreference target="RFC7696" to="AGILITY"/>
<displayreference target="RFC7208" to="SPF"/>
<displayreference target="RFC3597" to="RRTYPE"/>
<displayreference target="RFC2113" to="RAv4"/>
<displayreference target="RFC2711" to="RAv6"/>
<displayreference target="RFC1157" to="SNMPv1"/>
<displayreference target="RFC0793" to="TCP"/>
<displayreference target="RFC8684" to="MPTCP"/>
<displayreference target="RFC7413" to="TFO"/>
<displayreference target="RFC5246" to="TLS12"/>
<displayreference target="RFC8446" to="TLS13"/>
<displayreference target="RFC6066" to="TLS-EXT"/>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="HASH" target="https://www.cs.columbia.edu/~smb/papers/n ew-hash.pdf"> <reference anchor="HASH" target="https://www.cs.columbia.edu/~smb/papers/n ew-hash.pdf">
<front> <front>
<title>Deploying a New Hash Algorithm</title> <title>Deploying a New Hash Algorithm</title>
<author initials="S." surname="Bellovin" fullname="Steven M. Bellovin" > <author initials="S." surname="Bellovin" fullname="Steven M. Bellovin" >
<organization/> <organization/>
</author> </author>
<author initials="E." surname="Rescorla" fullname="Eric M. Rescorla"> <author initials="E." surname="Rescorla" fullname="Eric M. Rescorla">
<organization/> <organization/>
</author> </author>
<date year="2006"/> <date year="2006"/>
</front> </front>
<seriesInfo name="Proceedings of NDSS '06" value=""/> <refcontent>Proceedings of NDSS</refcontent>
</reference> </reference>
<reference anchor="SNI" target="https://mailarchive.ietf.org/arch/msg/tls/ 1t79gzNItZd71DwwoaqcQQ_4Yxc"> <reference anchor="SNI" target="https://mailarchive.ietf.org/arch/msg/tls/ 1t79gzNItZd71DwwoaqcQQ_4Yxc">
<front> <front>
<title>Accepting that other SNI name types will never work</title> <title>[TLS] Accepting that other SNI name types will never work.</tit le>
<author initials="A." surname="Langley" fullname="Adam Langley"> <author initials="A." surname="Langley" fullname="Adam Langley">
<organization/> <organization/>
</author> </author>
<date year="2016" month="March" day="03"/> <date year="2016" month="March"/>
</front> </front>
</reference> </reference>
<reference anchor="INTOLERANCE" target="https://mailarchive.ietf.org/arch/ msg/tls/bOJ2JQc3HjAHFFWCiNTIb0JuMZc"> <reference anchor="INTOLERANCE" target="https://mailarchive.ietf.org/arch/ msg/tls/bOJ2JQc3HjAHFFWCiNTIb0JuMZc">
<front> <front>
<title>Re: [TLS] Thoughts on Version Intolerance</title> <title>Re: [TLS] Thoughts on Version Intolerance</title>
<author initials="H." surname="Kario" fullname="Hubert Kario"> <author initials="H." surname="Kario" fullname="Hubert Kario">
<organization/> <organization/>
</author> </author>
<date year="2016" month="July" day="20"/> <date year="2016" month="July"/>
</front> </front>
</reference> </reference>
<reference anchor="DNSFLAGDAY" target="https://dnsflagday.net/2019/"> <reference anchor="DNSFLAGDAY" target="https://dnsflagday.net/2019/">
<front> <front>
<title>DNS Flag Day 2019</title> <title>DNS Flag Day 2019</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2019" month="May"/> <date year="2019" month="May"/>
</front> </front>
</reference> </reference>
<reference anchor="MPTCP-HOW-HARD" target="https://www.usenix.org/conferen ce/nsdi12/technical-sessions/presentation/raiciu"> <reference anchor="MPTCP-HOW-HARD" target="https://www.usenix.org/conferen ce/nsdi12/technical-sessions/presentation/raiciu">
<front> <front>
<title>How Hard Can It Be? Designing and Implementing a Deployable Mul tipath TCP</title> <title>How Hard Can It Be? Designing and Implementing a Deployable Mul tipath TCP</title>
<author initials="C." surname="Raiciu" fullname="Costin Raiciu"> <author initials="C." surname="Raiciu" fullname="Costin Raiciu">
<organization/> <organization/>
</author> </author>
<author initials="C." surname="Paasch" fullname="Christoph Paasch"> <author initials="C." surname="Paasch" fullname="Christoph Paasch">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Barre" fullname="Sebastien Barre"> <author initials="S." surname="Barre" fullname="Sebastien Barre">
skipping to change at line 507 skipping to change at line 593
</author> </author>
<author initials="O." surname="Bonaventure" fullname="Olivier Bonavent ure"> <author initials="O." surname="Bonaventure" fullname="Olivier Bonavent ure">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Handley" fullname="Mark Handley"> <author initials="M." surname="Handley" fullname="Mark Handley">
<organization/> <organization/>
</author> </author>
<date year="2012" month="April"/> <date year="2012" month="April"/>
</front> </front>
</reference> </reference>
<reference anchor="HTTP">
<front>
<title>HTTP Semantics</title>
<author fullname="Roy T. Fielding">
<organization>Adobe</organization>
</author>
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke">
<organization>greenbytes GmbH</organization>
</author>
<date day="12" month="September" year="2021"/>
<abstract>
<t> The Hypertext Transfer Protocol (HTTP) is a stateless applicat
ion-
level protocol for distributed, collaborative, hypertext information
systems. This document describes the overall architecture of HTTP,
establishes common terminology, and defines aspects of the protocol
that are shared by all versions. In this definition are core
protocol elements, extensibility mechanisms, and the "http" and
"https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC <reference anchor='I-D.ietf-httpbis-semantics'>
7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions <front>
of RFC 7230. <title>HTTP Semantics</title>
<author initials='R' surname='Fielding' fullname='Roy Fielding' role="editor">
<organization />
</author>
<author initials='M' surname='Nottingham' fullname='Mark Nottingham' role="edito
r">
<organization />
</author>
<author initials='J' surname='Reschke' fullname='Julian Reschke' role="editor">
<organization />
</author>
<date year='2021' month='September' />
</t> </front>
</abstract> <seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-semantics-19'/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-19
"/>
</reference>
<reference anchor="HTTP11">
<front>
<title>HTTP/1.1</title>
<author fullname="Roy T. Fielding">
<organization>Adobe</organization>
</author>
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke">
<organization>greenbytes GmbH</organization>
</author>
<date day="12" month="September" year="2021"/>
<abstract>
<t> The Hypertext Transfer Protocol (HTTP) is a stateless applicat
ion-
level protocol for distributed, collaborative, hypertext information
systems. This document specifies the HTTP/1.1 message syntax,
message parsing, connection management, and related security
concerns.
This document obsoletes portions of RFC 7230. </reference>
<reference anchor='I-D.ietf-httpbis-messaging'>
<front>
<title>HTTP/1.1</title>
<author initials='R' surname='Fielding' fullname='Roy Fielding' role="editor"/>
<author initials='M' surname='Nottingham' fullname='Mark Nottingham' role="edito
r"/>
<author initials='J' surname='Reschke' fullname='Julian Reschke' role="editor"/>
<date year='2021' month='September'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-messaging-19'/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5704.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5218.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8170.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6709.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2464.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.
xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-messaging-19
"/>
</reference>
<reference anchor="RFC5704">
<front>
<title>Uncoordinated Protocol Development Considered Harmful</title>
<author fullname="S. Bryant" initials="S." role="editor" surname="Brya
nt">
<organization/>
</author>
<author fullname="M. Morrow" initials="M." role="editor" surname="Morr
ow">
<organization/>
</author>
<author>
<organization>IAB</organization>
</author>
<date month="November" year="2009"/>
<abstract>
<t>This document identifies problems that may result from the absenc
e of formal coordination and joint development on protocols of mutual interest b
etween standards development organizations (SDOs). Some of these problems may c
ause significant harm to the Internet. The document suggests that a robust proc
edure is required prevent this from occurring in the future. The IAB has select
ed a number of case studies, such as Transport MPLS (T-MPLS), as recent examples
to describe the hazard to the Internet architecture that results from uncoordin
ated adaptation of a protocol.</t>
<t>This experience has resulted in a considerable improvement in the
relationship between the IETF and the ITU-T. In particular, this was achieved
via the establishment of the "Joint working team on MPLS-TP". In addition, the
leadership of the two organizations agreed to improve inter-organizational worki
ng practices so as to avoid conflict in the future between ITU-T Recommendations
and IETF RFCs.</t>
<t>Whilst we use ITU-T - IETF interactions in these case studies, th
e scope of the document extends to all SDOs that have an overlapping protocol in
terest with the IETF. This memo provides information for the Internet community
.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5704"/>
<seriesInfo name="DOI" value="10.17487/RFC5704"/>
</reference>
<reference anchor="SUCCESS">
<front>
<title>What Makes for a Successful Protocol?</title>
<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization/>
</author>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization/>
</author>
<date month="July" year="2008"/>
<abstract>
<t>The Internet community has specified a large number of protocols
to date, and these protocols have achieved varying degrees of success. Based on
case studies, this document attempts to ascertain factors that contribute to or
hinder a protocol's success. It is hoped that these observations can serve as g
uidance for future protocol work. This memo provides information for the Inter
net community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5218"/>
<seriesInfo name="DOI" value="10.17487/RFC5218"/>
</reference>
<reference anchor="TRANSITIONS">
<front>
<title>Planning for Protocol Adoption and Subsequent Transitions</titl
e>
<author fullname="D. Thaler" initials="D." role="editor" surname="Thal
er">
<organization/>
</author>
<date month="May" year="2017"/>
<abstract>
<t>Over the many years since the introduction of the Internet Protoc
ol, we have seen a number of transitions throughout the protocol stack, such as
deploying a new protocol, or updating or replacing an existing protocol. Many p
rotocols and technologies were not designed to enable smooth transition to alter
natives or to easily deploy extensions; thus, some transitions, such as the intr
oduction of IPv6, have been difficult. This document attempts to summarize some
basic principles to enable future transitions, and it also summarizes what make
s for a good transition plan.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8170"/>
<seriesInfo name="DOI" value="10.17487/RFC8170"/>
</reference>
<reference anchor="EXTENSIBILITY">
<front>
<title>Design Considerations for Protocol Extensions</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter">
<organization/>
</author>
<author fullname="B. Aboba" initials="B." role="editor" surname="Aboba
">
<organization/>
</author>
<author fullname="S. Cheshire" initials="S." surname="Cheshire">
<organization/>
</author>
<date month="September" year="2012"/>
<abstract>
<t>This document discusses architectural issues related to the exten
sibility of Internet protocols, with a focus on design considerations. It is in
tended to assist designers of both base protocols and extensions. Case studies
are included. A companion document, RFC 4775 (BCP 125), discusses procedures re
lating to the extensibility of IETF protocols. This document is not an Interne
t Standards Track specification; it is published for informational purposes.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="6709"/>
<seriesInfo name="DOI" value="10.17487/RFC6709"/>
</reference>
<reference anchor="RFC2464">
<front>
<title>Transmission of IPv6 Packets over Ethernet Networks</title>
<author fullname="M. Crawford" initials="M." surname="Crawford">
<organization/>
</author>
<date month="December" year="1998"/>
<abstract>
<t>This document specifies the frame format for transmission of IPv6
packets and the method of forming IPv6 link-local addresses and statelessly aut
oconfigured addresses on Ethernet networks. It also specifies the content of th
e Source/Target Link-layer Address option used in Router Solicitation, Router Ad
vertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages
when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2464"/>
<seriesInfo name="DOI" value="10.17487/RFC2464"/>
</reference>
<reference anchor="ALPN">
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negot
iation Extension</title>
<author fullname="S. Friedl" initials="S." surname="Friedl">
<organization/>
</author>
<author fullname="A. Popov" initials="A." surname="Popov">
<organization/>
</author>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<author fullname="E. Stephan" initials="E." surname="Stephan">
<organization/>
</author>
<date month="July" year="2014"/>
<abstract>
<t>This document describes a Transport Layer Security (TLS) extensio
n for application-layer protocol negotiation within the TLS handshake. For insta
nces in which multiple application protocols are supported on the same TCP or UD
P port, this extension allows the application layer to negotiate which protocol
will be used within the TLS connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7301"/>
<seriesInfo name="DOI" value="10.17487/RFC7301"/>
</reference>
<reference anchor="NEW-PROTOCOLS"> <reference anchor="NEW-PROTOCOLS">
<front> <front>
<title>On the usability of transport protocols other than TCP: A home gateway and internet path traversal study</title> <title>On the usability of transport protocols other than TCP: A home gateway and internet path traversal study</title>
<author fullname="Runa Barik" initials="R." surname="Barik"> <author fullname="Runa Barik" initials="R." surname="Barik">
<organization/> <organization/>
</author> </author>
<author fullname="Michael Welzl" initials="M." surname="Welzl"> <author fullname="Michael Welzl" initials="M." surname="Welzl">
<organization/> <organization/>
</author> </author>
<author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst"> <author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst">
skipping to change at line 698 skipping to change at line 654
<organization/> <organization/>
</author> </author>
<author fullname="Thomas Dreibholz" initials="T." surname="Dreibholz"> <author fullname="Thomas Dreibholz" initials="T." surname="Dreibholz">
<organization/> <organization/>
</author> </author>
<author fullname="Stein Gjessing" initials="S." surname="Gjessing"> <author fullname="Stein Gjessing" initials="S." surname="Gjessing">
<organization/> <organization/>
</author> </author>
<date month="May" year="2020"/> <date month="May" year="2020"/>
</front> </front>
<seriesInfo name="Computer Networks" value="Vol. 173, pp. 107211"/> <refcontent>Computer Networks, Vol. 173, pp. 107211</refcontent>
<seriesInfo name="DOI" value="10.1016/j.comnet.2020.107211"/> <seriesInfo name="DOI" value="10.1016/j.comnet.2020.107211"/>
</reference> </reference>
<reference anchor="GREASE">
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8701.
<title>Applying Generate Random Extensions And Sustain Extensibility ( xml"/>
GREASE) to TLS Extensibility</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.
<author fullname="D. Benjamin" initials="D." surname="Benjamin"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.
</author> xml"/>
<date month="January" year="2020"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.
<abstract> xml"/>
<t>This document describes GREASE (Generate Random Extensions And Su <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6733.
stain Extensibility), a mechanism to prevent extensibility failures in the TLS e xml"/>
cosystem. It reserves a set of TLS protocol values that may be advertised to ens <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8941.
ure peers correctly handle unknown values.</t> xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.
</front> xml"/>
<seriesInfo name="RFC" value="8701"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8999.
<seriesInfo name="DOI" value="10.17487/RFC8701"/> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8558.
<reference anchor="QUIC"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7838.
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> xml"/>
<author fullname="J. Iyengar" initials="J." role="editor" surname="Iye <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489.
ngar"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8460.
</author> xml"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="Tho <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7696.
mson"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7208.
</author> xml"/>
<date month="May" year="2021"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3597.
<abstract> xml"/>
<t>This document defines the core of the QUIC transport protocol. Q <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.
UIC provides applications with flow-controlled streams for structured communicat xml"/>
ion, low-latency connection establishment, and network path migration. QUIC incl <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.
udes security measures that ensure confidentiality, integrity, and availability xml"/>
in a range of deployment circumstances. Accompanying documents describe the int <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2113.
egration of TLS for key negotiation, loss detection, and an exemplary congestion xml"/>
control algorithm.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2711.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1157.
<seriesInfo name="RFC" value="9000"/> xml"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.
</reference> xml"/>
<reference anchor="SMTP">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization/>
</author>
<date month="October" year="2008"/>
<abstract>
<t>This document is a specification of the basic protocol for Intern
et electronic mail transport. It consolidates, updates, and clarifies several p
revious documents, making all or parts of most of them obsolete. It covers the
SMTP extension mechanisms and best practices for the contemporary Internet, but
does not provide details about particular extensions. Although SMTP was designe
d as a mail transport and delivery protocol, this specification also contains in
formation that is important to its use as a "mail submission" protocol for "spli
t-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRA
CK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5321"/>
<seriesInfo name="DOI" value="10.17487/RFC5321"/>
</reference>
<reference anchor="SIP">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization/>
</author>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization/>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization/>
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization/>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization/>
</author>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization/>
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization/>
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization/>
</author>
<date month="June" year="2002"/>
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an app
lication-layer control (signaling) protocol for creating, modifying, and termina
ting sessions with one or more participants. These sessions include Internet te
lephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>
<reference anchor="DIAMETER">
<front>
<title>Diameter Base Protocol</title>
<author fullname="V. Fajardo" initials="V." role="editor" surname="Faj
ardo">
<organization/>
</author>
<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization/>
</author>
<author fullname="J. Loughney" initials="J." surname="Loughney">
<organization/>
</author>
<author fullname="G. Zorn" initials="G." role="editor" surname="Zorn">
<organization/>
</author>
<date month="October" year="2012"/>
<abstract>
<t>The Diameter base protocol is intended to provide an Authenticati
on, Authorization, and Accounting (AAA) framework for applications such as netwo
rk access or IP mobility in both local and roaming situations. This document sp
ecifies the message format, transport, error reporting, accounting, and security
services used by all Diameter applications. The Diameter base protocol as defi
ned in this document obsoletes RFC 3588 and RFC 5719, and it must be supported b
y all new Diameter implementations. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6733"/>
<seriesInfo name="DOI" value="10.17487/RFC6733"/>
</reference>
<reference anchor="HTTP-HEADERS">
<front>
<title>Structured Field Values for HTTP</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="P-H. Kamp" initials="P-H." surname="Kamp">
<organization/>
</author>
<date month="February" year="2021"/>
<abstract>
<t>This document describes a set of data types and associated algori
thms that are intended to make it easier and safer to define and handle HTTP hea
der and trailer fields, known as "Structured Fields", "Structured Headers", or "
Structured Trailers". It is intended for use by specifications of new HTTP field
s that wish to use a common syntax that is more restrictive than traditional HTT
P field values.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8941"/>
<seriesInfo name="DOI" value="10.17487/RFC8941"/>
</reference>
<reference anchor="EDNS">
<front>
<title>Extension Mechanisms for DNS (EDNS(0))</title>
<author fullname="J. Damas" initials="J." surname="Damas">
<organization/>
</author>
<author fullname="M. Graff" initials="M." surname="Graff">
<organization/>
</author>
<author fullname="P. Vixie" initials="P." surname="Vixie">
<organization/>
</author>
<date month="April" year="2013"/>
<abstract>
<t>The Domain Name System's wire protocol includes a number of fixed
fields whose range has been or soon will be exhausted and does not allow reques
tors to advertise their capabilities to responders. This document describes bac
kward-compatible mechanisms for allowing the protocol to grow.</t>
<t>This document updates the Extension Mechanisms for DNS (EDNS(0))
specification (and obsoletes RFC 2671) based on feedback from deployment experie
nce in several implementations. It also obsoletes RFC 2673 ("Binary Labels in t
he Domain Name System") and adds considerations on the use of extended labels in
the DNS.</t>
</abstract>
</front>
<seriesInfo name="STD" value="75"/>
<seriesInfo name="RFC" value="6891"/>
<seriesInfo name="DOI" value="10.17487/RFC6891"/>
</reference>
<reference anchor="QUIC-INVARIANTS">
<front>
<title>Version-Independent Properties of QUIC</title>
<author fullname="M. Thomson" initials="M." surname="Thomson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the properties of the QUIC transport protoc
ol that are common to all versions of the protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8999"/>
<seriesInfo name="DOI" value="10.17487/RFC8999"/>
</reference>
<reference anchor="PATH-SIGNALS">
<front>
<title>Transport Protocol Path Signals</title>
<author fullname="T. Hardie" initials="T." role="editor" surname="Hard
ie">
<organization/>
</author>
<date month="April" year="2019"/>
<abstract>
<t>This document discusses the nature of signals seen by on-path ele
ments examining transport protocols, contrasting implicit and explicit signals.
For example, TCP's state machine uses a series of well-known messages that are
exchanged in the clear. Because these are visible to network elements on the pa
th between the two nodes setting up the transport connection, they are often use
d as signals by those network elements. In transports that do not exchange thes
e messages in the clear, on-path network elements lack those signals. Often, the
removal of those signals is intended by those moving the messages to confidenti
al channels. Where the endpoints desire that network elements along the path re
ceive these signals, this document recommends explicit signals be used.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8558"/>
<seriesInfo name="DOI" value="10.17487/RFC8558"/>
</reference>
<reference anchor="ALT-SVC">
<front>
<title>HTTP Alternative Services</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="P. McManus" initials="P." surname="McManus">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." surname="Reschke">
<organization/>
</author>
<date month="April" year="2016"/>
<abstract>
<t>This document specifies "Alternative Services" for HTTP, which al
low an origin's resources to be authoritatively available at a separate network
location, possibly accessed with a different protocol configuration.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7838"/>
<seriesInfo name="DOI" value="10.17487/RFC7838"/>
</reference>
<reference anchor="DMARC">
<front>
<title>Domain-based Message Authentication, Reporting, and Conformance
(DMARC)</title>
<author fullname="M. Kucherawy" initials="M." role="editor" surname="K
ucherawy">
<organization/>
</author>
<author fullname="E. Zwicky" initials="E." role="editor" surname="Zwic
ky">
<organization/>
</author>
<date month="March" year="2015"/>
<abstract>
<t>Domain-based Message Authentication, Reporting, and Conformance (
DMARC) is a scalable mechanism by which a mail-originating organization can expr
ess domain-level policies and preferences for message validation, disposition, a
nd reporting, that a mail-receiving organization can use to improve mail handlin
g.</t>
<t>Originators of Internet Mail need to be able to associate reliabl
e and authenticated domain identifiers with messages, communicate policies about
messages that use those identifiers, and report about mail using those identifi
ers. These abilities have several benefits: Receivers can provide feedback to D
omain Owners about the use of their domains; this feedback can provide valuable
insight about the management of internal operations and the presence of external
domain name abuse.</t>
<t>DMARC does not produce or encourage elevated delivery privilege o
f authenticated email. DMARC is a mechanism for policy distribution that enable
s increasingly strict handling of messages that fail authentication checks, rang
ing from no action, through altered delivery, up to message rejection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7489"/>
<seriesInfo name="DOI" value="10.17487/RFC7489"/>
</reference>
<reference anchor="SMTP-TLS-Reporting">
<front>
<title>SMTP TLS Reporting</title>
<author fullname="D. Margolis" initials="D." surname="Margolis">
<organization/>
</author>
<author fullname="A. Brotman" initials="A." surname="Brotman">
<organization/>
</author>
<author fullname="B. Ramakrishnan" initials="B." surname="Ramakrishnan
">
<organization/>
</author>
<author fullname="J. Jones" initials="J." surname="Jones">
<organization/>
</author>
<author fullname="M. Risher" initials="M." surname="Risher">
<organization/>
</author>
<date month="September" year="2018"/>
<abstract>
<t>A number of protocols exist for establishing encrypted channels b
etween SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authenti
cation of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS
). These protocols can fail due to misconfiguration or active attack, leading t
o undelivered messages or delivery over unencrypted or unauthenticated channels.
This document describes a reporting mechanism and format by which sending syst
ems can share statistics and specific information about potential failures with
recipient domains. Recipient domains can then use this information to both dete
ct potential attacks and diagnose unintentional misconfigurations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8460"/>
<seriesInfo name="DOI" value="10.17487/RFC8460"/>
</reference>
<reference anchor="AGILITY">
<front>
<title>Guidelines for Cryptographic Algorithm Agility and Selecting Ma
ndatory-to-Implement Algorithms</title>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<date month="November" year="2015"/>
<abstract>
<t>Many IETF protocols use cryptographic algorithms to provide confi
dentiality, integrity, authentication, or digital signature. Communicating peer
s must support a common set of cryptographic algorithms for these mechanisms to
work properly. This memo provides guidelines to ensure that protocols have the
ability to migrate from one mandatory-to-implement algorithm suite to another ov
er time.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="201"/>
<seriesInfo name="RFC" value="7696"/>
<seriesInfo name="DOI" value="10.17487/RFC7696"/>
</reference>
<reference anchor="SPF">
<front>
<title>Sender Policy Framework (SPF) for Authorizing Use of Domains in
Email, Version 1</title>
<author fullname="S. Kitterman" initials="S." surname="Kitterman">
<organization/>
</author>
<date month="April" year="2014"/>
<abstract>
<t>Email on the Internet can be forged in a number of ways. In part
icular, existing protocols place no restriction on what a sending host can use a
s the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO command
s. This document describes version 1 of the Sender Policy Framework (SPF) proto
col, whereby ADministrative Management Domains (ADMDs) can explicitly authorize
the hosts that are allowed to use their domain names, and a receiving host can c
heck such authorization.</t>
<t>This document obsoletes RFC 4408.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7208"/>
<seriesInfo name="DOI" value="10.17487/RFC7208"/>
</reference>
<reference anchor="RRTYPE">
<front>
<title>Handling of Unknown DNS Resource Record (RR) Types</title>
<author fullname="A. Gustafsson" initials="A." surname="Gustafsson">
<organization/>
</author>
<date month="September" year="2003"/>
<abstract>
<t>Extending the Domain Name System (DNS) with new Resource Record (
RR) types currently requires changes to name server software. This document spe
cifies the changes necessary to allow future DNS implementations to handle new R
R types transparently. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3597"/>
<seriesInfo name="DOI" value="10.17487/RFC3597"/>
</reference>
<reference anchor="RFC0988">
<front>
<title>Host extensions for IP multicasting</title>
<author fullname="S.E. Deering" initials="S.E." surname="Deering">
<organization/>
</author>
<date month="July" year="1986"/>
<abstract>
<t>This memo specifies the extensions required of a host implementat
ion of the Internet Protocol (IP) to support internetwork multicasting. This
specification supersedes that given in RFC-966, and constitutes a propose
d protocol standard for IP multicasting in the ARPA-Internet. The reader is d
irected to RFC-966 for a discussion of the motivation and rationale behind th
e multicasting extension specified here.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="988"/>
<seriesInfo name="DOI" value="10.17487/RFC0988"/>
</reference>
<reference anchor="RFC0791">
<front>
<title>Internet Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization/>
</author>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="5"/>
<seriesInfo name="RFC" value="791"/>
<seriesInfo name="DOI" value="10.17487/RFC0791"/>
</reference>
<reference anchor="RAv4">
<front>
<title>IP Router Alert Option</title>
<author fullname="D. Katz" initials="D." surname="Katz">
<organization/>
</author>
<date month="February" year="1997"/>
<abstract>
<t>This memo describes a new IP Option type that alerts transit rout
ers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2113"/>
<seriesInfo name="DOI" value="10.17487/RFC2113"/>
</reference>
<reference anchor="RAv6">
<front>
<title>IPv6 Router Alert Option</title>
<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization/>
</author>
<author fullname="A. Jackson" initials="A." surname="Jackson">
<organization/>
</author>
<date month="October" year="1999"/>
<abstract>
<t>This memo describes a new IPv6 Hop-by-Hop Option type that alerts
transit routers to more closely examine the contents of an IP datagram. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2711"/>
<seriesInfo name="DOI" value="10.17487/RFC2711"/>
</reference>
<reference anchor="SNMPv1">
<front>
<title>Simple Network Management Protocol (SNMP)</title>
<author fullname="J.D. Case" initials="J.D." surname="Case">
<organization/>
</author>
<author fullname="M. Fedor" initials="M." surname="Fedor">
<organization/>
</author>
<author fullname="M.L. Schoffstall" initials="M.L." surname="Schoffsta
ll">
<organization/>
</author>
<author fullname="J. Davin" initials="J." surname="Davin">
<organization/>
</author>
<date month="May" year="1990"/>
<abstract>
<t>This RFC is a re-release of RFC 1098, with a changed "Status of t
his Memo" section plus a few minor typographical corrections. This memo defines
a simple protocol by which management information for a network element may be
inspected or altered by logically remote users. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1157"/>
<seriesInfo name="DOI" value="10.17487/RFC1157"/>
</reference>
<reference anchor="TCP">
<front>
<title>Transmission Control Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization/>
</author>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="793"/>
<seriesInfo name="DOI" value="10.17487/RFC0793"/>
</reference>
<reference anchor="EXT-TCP"> <reference anchor="EXT-TCP">
<front> <front>
<title>Is it still possible to extend TCP?</title> <title>Is it still possible to extend TCP?</title>
<author fullname="Michio Honda" initials="M." surname="Honda"> <author fullname="Michio Honda" initials="M." surname="Honda">
<organization/> <organization/>
</author> </author>
<author fullname="Yoshifumi Nishida" initials="Y." surname="Nishida"> <author fullname="Yoshifumi Nishida" initials="Y." surname="Nishida">
<organization/> <organization/>
</author> </author>
<author fullname="Costin Raiciu" initials="C." surname="Raiciu"> <author fullname="Costin Raiciu" initials="C." surname="Raiciu">
skipping to change at line 1093 skipping to change at line 701
</author> </author>
<author fullname="Adam Greenhalgh" initials="A." surname="Greenhalgh"> <author fullname="Adam Greenhalgh" initials="A." surname="Greenhalgh">
<organization/> <organization/>
</author> </author>
<author fullname="Mark Handley" initials="M." surname="Handley"> <author fullname="Mark Handley" initials="M." surname="Handley">
<organization/> <organization/>
</author> </author>
<author fullname="Hideyuki Tokuda" initials="H." surname="Tokuda"> <author fullname="Hideyuki Tokuda" initials="H." surname="Tokuda">
<organization/> <organization/>
</author> </author>
<date year="2011"/> <date month="November" year="2011"/>
</front>
<seriesInfo name="Proceedings of the 2011 ACM SIGCOMM conference on Inte </front>
rnet measurement conference - IMC" value="'11"/> <refcontent>IMC '11: Proceedings of the 2011 ACM SIGCOMM conference on I
nternet measurement conference</refcontent>
<seriesInfo name="DOI" value="10.1145/2068816.2068834"/> <seriesInfo name="DOI" value="10.1145/2068816.2068834"/>
</reference> </reference>
<reference anchor="MPTCP">
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8684.
<title>TCP Extensions for Multipath Operation with Multiple Addresses< xml"/>
/title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7413.
<author fullname="A. Ford" initials="A." surname="Ford"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.
</author> xml"/>
<author fullname="C. Raiciu" initials="C." surname="Raiciu"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066.
<author fullname="M. Handley" initials="M." surname="Handley"> xml"/>
<organization/>
</author>
<author fullname="O. Bonaventure" initials="O." surname="Bonaventure">
<organization/>
</author>
<date month="January" year="2013"/>
<abstract>
<t>TCP/IP communication is currently restricted to a single path per
connection, yet multiple paths often exist between peers. The simultaneous use
of these multiple paths for a TCP/IP session would improve resource usage withi
n the network and, thus, improve user experience through higher throughput and i
mproved resilience to network failure.</t>
<t>Multipath TCP provides the ability to simultaneously use multiple
paths between peers. This document presents a set of extensions to traditional
TCP to support multipath operation. The protocol offers the same type of servi
ce to applications as TCP (i.e., reliable bytestream), and it provides the compo
nents necessary to establish and use multiple TCP flows across potentially disjo
int paths. This document defines an Experimental Protocol for the Internet com
munity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6824"/>
<seriesInfo name="DOI" value="10.17487/RFC6824"/>
</reference>
<reference anchor="TFO">
<front>
<title>TCP Fast Open</title>
<author fullname="Y. Cheng" initials="Y." surname="Cheng">
<organization/>
</author>
<author fullname="J. Chu" initials="J." surname="Chu">
<organization/>
</author>
<author fullname="S. Radhakrishnan" initials="S." surname="Radhakrishn
an">
<organization/>
</author>
<author fullname="A. Jain" initials="A." surname="Jain">
<organization/>
</author>
<date month="December" year="2014"/>
<abstract>
<t>This document describes an experimental TCP mechanism called TCP
Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets a
nd consumed by the receiving end during the initial connection handshake, and sa
ves up to one full round-trip time (RTT) compared to the standard TCP, which req
uires a three-way handshake (3WHS) to complete before data can be exchanged. Ho
wever, TFO deviates from the standard TCP semantics, since the data in the SYN c
ould be replayed to an application in some rare circumstances. Applications sho
uld not use TFO unless they can tolerate this issue, as detailed in the Applicab
ility section.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7413"/>
<seriesInfo name="DOI" value="10.17487/RFC7413"/>
</reference>
<reference anchor="TLS12">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author fullname="T. Dierks" initials="T." surname="Dierks">
<organization/>
</author>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="August" year="2008"/>
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Securi
ty (TLS) protocol. The TLS protocol provides communications security over the I
nternet. The protocol allows client/server applications to communicate in a way
that is designed to prevent eavesdropping, tampering, or message forgery. [STA
NDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5246"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
</reference>
<reference anchor="TLS13">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Securi
ty (TLS) protocol. TLS allows client/server applications to communicate over th
e Internet in a way that is designed to prevent eavesdropping, tampering, and me
ssage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077
, 5246, and 6961. This document also specifies new requirements for TLS 1.2 imp
lementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="TLS-EXT">
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definition
s</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd
">
<organization/>
</author>
<date month="January" year="2011"/>
<abstract>
<t>This document provides specifications for existing TLS extensions
. It is a companion document for RFC 5246, "The Transport Layer Security (TLS)
Protocol Version 1.2". The extensions specified are server_name, max_fragment_l
ength, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_reque
st. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6066"/>
<seriesInfo name="DOI" value="10.17487/RFC6066"/>
</reference>
</references> </references>
<section anchor="examples" numbered="true" toc="default"> <section anchor="examples" numbered="true" toc="default">
<name>Examples</name> <name>Examples</name>
<t>This appendix contains a brief study of problems in a range of Internet <t>This appendix contains a brief study of problems in a range of
protocols at different layers of the stack.</t> Internet protocols at different layers of the stack.</t>
<section anchor="dns" numbered="true" toc="default"> <section anchor="dns" numbered="true" toc="default">
<name>DNS</name> <name>DNS</name>
<t>Ossified DNS code bases and systems resulted in new Resource Record C
odes <t>Ossified DNS code bases and systems resulted in new Resource Record
(RRCodes) being unusable. A new codepoint would take years of coordination Codes (RRCodes) being unusable. A new code point would take years of
between implementations and deployments before it could be relied upon. coordination between implementations and deployments before it could
Consequently, overloading use of the TXT record was used to avoid effort and be relied upon.
delays involved, a method used in the Sender Policy Framework <xref target="SPF"
format="default"/> Consequently, use of the TXT record was overloaded in order to avoid
and other protocols.</t> the effort and delays involved in allocating new code points; this
<t>It was not until after the standard mechanism for dealing with new RR approach was used in the Sender Policy Framework <xref
Codes target="RFC7208" format="default"/> and other protocols.
<xref target="RRTYPE" format="default"/> was considered widely deployed that new
RRCodes can be </t>
safely created and used.</t> <t>It was not until after the standard mechanism for dealing with new
RRCodes <xref target="RFC3597" format="default"/> was considered
widely deployed that new RRCodes could be safely created and used.</t>
</section> </section>
<section anchor="http" numbered="true" toc="default"> <section anchor="HTTP" numbered="true" toc="default">
<name>HTTP</name> <name>HTTP</name>
<t>HTTP has a number of very effective extension points in addition to t <t>HTTP has a number of very effective extension points in addition to
he the aforementioned header fields. It also has some examples of
aforementioned header fields. It also has some examples of extension points extension points that are so rarely used that it is possible that they
that are so rarely used that it is possible that they are not at all usable.</t> are not at all usable.</t>
<t>Extension points in HTTP that might be unwise to use include the exte <t>Extension points in HTTP that might be unwise to use include the
nsion point extension point on each chunk in the chunked transfer coding (<xref
on each chunk in the chunked transfer coding <xref section="7.1" sectionFormat=" section="7.1" sectionFormat="of" target="I-D.ietf-httpbis-messaging" for
of" target="HTTP11" format="default"/>, the mat="default"/>),
ability to use transfer codings other than the chunked coding, and the range the ability to use transfer codings other than the chunked coding, and
unit in a range request <xref section="14" sectionFormat="of" target="HTTP" form the range unit in a range request (<xref section="14"
at="default"/>.</t> sectionFormat="of" target="I-D.ietf-httpbis-semantics" format="default"/
>).</t>
</section> </section>
<section anchor="ip" numbered="true" toc="default"> <section anchor="ip" numbered="true" toc="default">
<name>IP</name> <name>IP</name>
<t>The version field in IP was rendered useless when encapsulated over E <t>The version field in IP was rendered useless when encapsulated over
thernet, Ethernet, requiring a new EtherType with IPv6 <xref target="RFC2464"
requring a new ethertype with IPv6 <xref target="RFC2464" format="default"/>, du format="default"/>, due in part to Layer 2 devices making
e in part to layer 2 devices version-independent assumptions about the structure of the IPv4
making version-independent assumptions about the structure of the IPv4 header.</ header.</t>
t> <t>Protocol identifiers or code points that are reserved for future use
<t>Protocol identifiers or codepoints that are reserved for future use c can be especially problematic. Reserving values without attributing
an be semantics to their use can result in diverse or conflicting semantics
especially problematic. Reserving values without attributing semantics to their being attributed without any hope of interoperability.
use can result in diverse or conflicting semantics being attributed without any
hope of interoperability. An example of this is the 224/3 "class E" address An example of this is the 224/3 address space in IPv4 that <xref
space in IPv4 <xref target="RFC0988" format="default"/>. This space was original target="RFC0791"/> reserved without assigning any semantics. <xref
ly reserved in <xref target="RFC0791" format="default"/> target="RFC1112"/> partially reclaimed that reserved address space for
without assigning any semantics and has since been partially reclaimed for use use in multicast (224/4), but the remaining address space (240/4) has
in multicast (224/4), but otherwise has not been successfully reclaimed for any not been successfully reclaimed for any purpose.
purpose (240/4)
<xref target="RFC0988" format="default"/>.</t> </t>
<t>For protocols that can use negotiation to attribute semantics to valu
es, it is <t>For protocols that can use negotiation to attribute semantics to
possible that unused codepoints can be reclaimed for active use, though this values, it is possible that unused code points can be reclaimed for
requires that the negotiation include all protocol participants. For something active use, though this requires that the negotiation include all
as fundamental as addressing, negotiation is difficult or even impossible, as protocol participants. For something as fundamental as addressing,
all nodes on the network path plus potential alternative paths would need to be negotiation is difficult or even impossible, as all nodes on the
involved.</t> network path plus potential alternative paths would need to be
<t>IP Router Alerts <xref target="RAv4" format="default"/><xref target=" involved.</t>
RAv6" format="default"/> use IP options or extension <t>IP Router Alerts <xref target="RFC2113" format="default"/><xref
headers to indicate that data is intended for consumption by the next hop router target="RFC2711" format="default"/> use IP options or extension
rather than the addressed destination. In part, the deployment of router alerts headers to indicate that data is intended for consumption by the next-ho
was unsuccessful due to the realities of processing IP packets at line rates, p
combined with bad assumptions in the protocol design about these performance router rather than the addressed destination. In part, the
constraints. However, this was not exclusively down to design problems or bugs deployment of router alerts was unsuccessful due to the realities of
as the capability was also deliberately blocked at some routers.</t> processing IP packets at line rates, combined with bad assumptions in
the protocol design about these performance constraints. However,
this was not exclusively down to design problems or bugs, as the
capability was also deliberately blocked at some routers.</t>
</section> </section>
<section anchor="snmp" numbered="true" toc="default"> <section anchor="snmp" numbered="true" toc="default">
<name>SNMP</name> <name>SNMP</name>
<t>As a counter example, the first version of the Simple Network Managem ent <t>As a counter example, the first version of the Simple Network Managem ent
Protocol (SNMP) <xref target="SNMPv1" format="default"/> defines that unparseabl e or unauthenticated Protocol (SNMP) <xref target="RFC1157" format="default"/> states that unparseabl e or unauthenticated
messages are simply discarded without response:</t> messages are simply discarded without response:</t>
<ul empty="true"> <blockquote>
<li> <t>It then verifies the version number of the SNMP message. If
<t>It then verifies the version number of the SNMP message. If there there is a mismatch, it discards the datagram and performs no
is a further actions.</t>
mismatch, it discards the datagram and performs no further actions.</t> </blockquote>
</li> <t>When SNMP versions 2, 2c, and 3 came along, older agents did exactly
</ul> what the protocol specifies. Deployment of new versions was likely
<t>When SNMP versions 2, 2c and 3 came along, older agents did exactly w successful because the handling of newer versions was both clear and
hat the simple.</t>
protocol specifies. Deployment of new versions was likely successful because
the handling of newer versions was both clear and simple.</t>
</section> </section>
<section anchor="tcp" numbered="true" toc="default"> <section anchor="tcp" numbered="true" toc="default">
<name>TCP</name> <name>TCP</name>
<t>Extension points in TCP <xref target="TCP" format="default"/> have be <t>Extension points in TCP <xref target="RFC0793" format="default"/>
en rendered difficult to use, have been rendered difficult to use largely due to middlebox
largely due to middlebox interactions; see interactions; see <xref target="EXT-TCP" format="default"/>.</t>
<xref target="EXT-TCP" format="default"/>.</t>
<t>For instance, multipath TCP <xref target="MPTCP" format="default"/> c <t>
an only be deployed For instance, multipath TCP (<xref target="RFC8684" format="default"/>) can
opportunistically; see <xref target="MPTCP-HOW-HARD" format="default"/>. As only be deployed opportunistically; see <xref target="MPTCP-HOW-HARD"
multipath TCP enables progressive enhancement of the protocol, this largely only format="default"/>. Since MPTCP is a protocol enhancement that doesn’t impair
causes the feature to not be available if the path is intolerant of the the connection if it is blocked, network path intolerance of the extension
extension.</t> only results in the multipath functionality becoming unavailable.
<t>In comparison, the deployment of Fast Open <xref target="TFO" format=
"default"/> critically depends </t>
on extension capability being widely available. Though very few network paths <t>In comparison, the deployment of TCP Fast Open (<xref
were intolerant of the extension in absolute terms, TCP Fast Open could not be target="RFC7413" format="default"/>) critically depends on extension
deployed as a result.</t> capability being widely available. Though very few network paths were
intolerant of the extension in absolute terms, TCP Fast Open could not
be deployed as a result.</t>
</section> </section>
<section anchor="tls" numbered="true" toc="default"> <section anchor="tls" numbered="true" toc="default">
<name>TLS</name> <name>TLS</name>
<t>Transport Layer Security (TLS) <xref target="TLS12" format="default"/ > provides examples of where a <t>Transport Layer Security (TLS) <xref target="RFC5246" format="default "/> provides examples of where a
design that is objectively sound fails when incorrectly implemented. TLS design that is objectively sound fails when incorrectly implemented. TLS
provides examples of failures in protocol version negotiation and extensibility. </t> provides examples of failures in protocol version negotiation and extensibility. </t>
<t>Version negotiation in TLS 1.2 and earlier uses the "Highest mutually supported <t>Version negotiation in TLS 1.2 and earlier uses the "Highest mutually supported
version (HMSV)" scheme exactly as it is described in <xref target="EXTENSIBILITY " format="default"/>. version (HMSV)" scheme exactly as it is described in <xref target="RFC6709" form at="default"/>.
However, clients are unable to advertise a new version without causing a However, clients are unable to advertise a new version without causing a
non-trivial proportion of sessions to fail due to bugs in server and middlebox non-trivial proportion of sessions to fail due to bugs in server and middlebox
implementations.</t> implementations.</t>
<t>Intolerance to new TLS versions is so severe <xref target="INTOLERANC E" format="default"/> that TLS 1.3 <t>Intolerance to new TLS versions is so severe <xref target="INTOLERANC E" format="default"/> that TLS 1.3
<xref target="TLS13" format="default"/> abandoned HMSV version negotiation for a <xref target="RFC8446" format="default"/> abandoned HMSV version negotiation for
new mechanism.</t> a new mechanism.</t>
<t>The server name indication (SNI) <xref target="TLS-EXT" format="defau <t>The server name indication (SNI) <xref target="RFC6066" format="defau
lt"/> in TLS is another lt"/> in TLS is another
excellent example of the failure of a well-designed extensibility point. SNI excellent example of the failure of a well-designed extensibility point. SNI
uses the same technique for extension that is used successfully in other parts uses the same technique for extensions that is used successfully in other parts
of the TLS protocol. The original design of SNI anticipated the ability to of the TLS protocol. The original design of SNI anticipated the ability to
include multiple names of different types.</t> include multiple names of different types.</t>
<t>SNI was originally defined with just one type of name: a domain name. No other <t>SNI was originally defined with just one type of name: a domain name. No other
type has ever been standardized, though several have been proposed. Despite an type has ever been standardized, though several have been proposed. Despite an
otherwise exemplary design, SNI is so inconsistently implemented that any hope otherwise exemplary design, SNI is so inconsistently implemented that any hope
for using the extension point it defines has been abandoned <xref target="SNI" f ormat="default"/>.</t> for using the extension point it defines has been abandoned <xref target="SNI" f ormat="default"/>.</t>
</section> </section>
</section> </section>
<section numbered="false">
<name>IAB Members at the Time of Approval
</name>
<t>
Internet Architecture Board members at the time this document was
approved for publication were:
</t>
<ul empty="true" spacing="compact" bare="false">
<li >
<t><contact fullname="Jari Arkko"/></t>
</li>
<li >
<t><contact fullname="Deborah Brungard"/></t>
</li>
<li>
<t><contact fullname="Ben Campbell"/></t>
</li>
<li >
<t><contact fullname="Lars Eggert"/></t>
</li>
<li>
<t><contact fullname="Wes Hardaker"/></t>
</li>
<li >
<t><contact fullname="Cullen Jennings"/></t>
</li>
<li>
<t><contact fullname="Mirja Kühlewind"/></t>
</li>
<li >
<t><contact fullname="Zhenbin Li"/></t>
</li>
<li>
<t><contact fullname="Jared Mauch"/></t>
</li>
<li >
<t><contact fullname="Tommy Pauly"/></t>
</li>
<li >
<t><contact fullname="David Schinazi"/></t>
</li>
<li>
<t><contact fullname="Russ White"/></t>
</li>
<li >
<t><contact fullname="Jiankang Yao"/></t>
</li>
</ul>
</section>
<section numbered="false" anchor="acknowledgments" toc="default"> <section numbered="false" anchor="acknowledgments" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>Toerless Eckert, Wes Hardaker, Mirja Kuehlewind, Eliot Lear, Mark Notti <t><contact fullname="Toerless Eckert"/>, <contact fullname="Wes Hardaker"
ngham, and />, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Eliot Lear"/>, <co
Brian Trammell made significant contributions to this document.</t> ntact fullname="Mark Nottingham"/>, and
<contact fullname="Brian Trammell"/> made significant contributions to this docu
ment.</t>
</section> </section>
</back>
<!-- ##markdown-source:
H4sIAO5JZmEAA519W3PcyJHue/0KhPSw0kZ38yINddnweimJGtErUTRJzazX
4XBUA9VsWGigDaBJtRk6v+y8nT928svMugDdGm+sYzxDsoG6ZOXly1v1dDo1
fdlX7nX26GNT3057166yX0o7L6uy32bNIrtsm77Jmyo7+9a7uiubOvvk8qWt
y27VPTJ2Pm/d3evsS+ey8z773GYfG/7RFE1e2xWNXLR20U9pzOmmc9Oynzbt
tGrkx8PnJre9u23a7eusrBeNKdft66xvN11/fHj46vDYmK63dfFXWzU1DbZ1
nVmXr7M/06ImWde0fesWHf20XckPNO3KrtdlffsXY+ymXzbta5NlU/p/RjN0
r7NPs+xm2ay6pua/ySI/2bYv68EHTXtLf2/+UVaV5T+4lS2r19mq/4+quXd1
3zbr7ax2/XD4m1l2aTfVNhn8plmttslfeeTT9bpy6bj9Gg/8h8XfZ3mzMqZu
2pXtyzv32hgD6oRfs+zD6fWH1/y6P8B3bl01W9p4ZrMLd599sN0yO62ItmW/
XD3iZyNB8L+p/ldXfj3L3riqau7KOnwgG7ju3Z2rQbnRA6MRzmbZlevyplWK
xRHO2jLH+4OPCzr61xmd84lsxLa3rqedLPt+3b0+OLi/v5/lHdGi2qzmpZ25
YnPwf7rV/GBt167tDmp3P13SLmfrYiH761xbug6komGIdXPnCqJIB06+eHd9
nf3L4ckjQ49eX5wPqXea527dg3r90vZZ0y9di6d4/Vm/XbsuuydWyGoiRZvd
N+3X/wFJT2fZR1vfVm47osdpYVeDjzwtjk6mh8/on/0UAafYNl8SE8xK1y9m
xEoH+MPBqrs96Kvu4Kh/8er2Hxfn/X8XL47e3d839u/5H//41+d/+pbzxs8v
bj5/PLs6vXh7NiTAFf3rzzcfr/8CIdjcLnsiWp39QnSGzJ/XfVO51ta5+x9s
+8Ms+0/bls1o0x82c9f2yUfppl9Mjw//t5uef/7D8R/+mD/78LfTD+/f//q2
vLg5nx/+YfPpv2XT7y6u3388/fnd6Z9GInNxnb2v7G32zm6xjFePhst6NT38
abAmv6Si7hb0XmFZARzg0QNM9Ony5u3l9MPnX6cfTq/eDSf70EAm2yJ7a2vo
yjfu99k7YtbbmmW2LrLzFYn+ijSLCLEItJ1XLvu0qfpybftlRuM/+rG0kIat
y29MoLypF651dGAHdVeUR8cHPentusxtNe1ch1PtDtatozd60ipNfdDaMi83
IxIcQ0fvOXA90rdNB715xa+OP1u2Zdc36yWpPtvly9HH125u6WXSK29s27rR
p6cVUel90xajv38qiRGa7ENTF3b00XsyWzTau02+dPV4vM9VeVeS4L5paku6
rN/szEgm4CsdUF1AJKFhb24uX2fn03fMdFOQeV52RLuVpRPKO33k6GjPQysi
sL2lY6SHrt6//enF4XPocDOdTjM77/rW5r0xN0uXeVPbNxms6q3L1mpxu6xw
a1cXLIfum2vzshP95OhXb4zBN3cipKYmQ9qXfJjZKhhpUWjdZr0ma6mTzDKS
8rKDtdyA4WhA4jVihmxJXNq62w1JnCFuguIkNRsWlS2cBe26LKfzoTXQzzJB
2dN7JKp1l60bYi+wLW2qYCY2Mm2Hv9gw2IxAhQXPd5mlYW5LGJl7Urwuq2z+
FXNjCbmlfxdZMsTcmRWtNivKxaLMSTbIpGY5sWK1nSmVV2VBB2nMY6iutik2
OchizClRglR91y02VdzVw8Pvr7+8fXt2ff07HNfx0cvv32nfruiSgyE+v7db
paclO3hPmzb4vIHIbni/NOwCZgKnxO/hyGQk2k5JWpU203Z0ALDRsj0Sx4mh
QYoSa+z4TOlXsElZix7GcEJKPi4aKpKRj4IkvSD2jn81vMyiIYrVjT/3rJl3
pMd7R2T6QhxK3GZ7An06aev+vilbVkFdRnAjnaRblguaGMavL1fgoHPM2q1p
oW5iSq+7rOxhVZIJyWzxN0JytM3BVPcESErZ02CbC/zJ+Bkn/EDcZLOpCjp5
4f3CFZOMF9gSVWzOU8eHZXZik4KsddWsXUHrPfu2BjwgjcgrAGPQclw/7Ugn
JjMldO5IHPTAnSUN1qxZuAidOdkGsyDUbM/8h3MlXroh+3p9fnP++YL56eXR
i0PiJ0fMXtbgYNklScgKmw4TuztCOiK94O5529iCOfq0TiR+3RC1MhJeG4U8
4ckuPTSWFT37guhlXL2EDS/2KIC4uKxbu7wkycoSphR2cvAQ6DmIKSCSiSTH
IdL/ibmzJalYHijRbgWbOmYzITDrFTrCVUM0LF1houK7Ky1eL1u/Elr8iABC
6RHXEZGXdPIVTr8zHZ0S/U4mqIXV4y2ysiGaB81BcBGCTTxIg+tOm4HKM17l
8Yziw9BEZH43TskCfceLjFuAQhvpqL4xmzUMqxKhy9tyrip3j1IiGbJfXbaA
UOKEojY2gRZeVxRumlCFwSstsdn0FZ9pB8xKFLCFnCb9CKkjx4u2L4pC5bUs
QA3W6wELRxFUDSx6Pqr5qBTEprkoaGIa2HUBrVKOo58JfhQNsRMZ1Gqb0ZOP
cHyufUT6fwtGahYGbERCCsBNiyazMMEKI5FYCqtyVfZE/5ocBXmPtA15dDmB
JqGKgFrT0YNk2mjybqNmRzEQRiXLvk2GlrOlvfCZkTaAnmC1ZIh6hWsWCzAP
Se0dzc0LgffGPhgzn2g0OtxbIhvWJxDs7xu1n3PhEdL9YMxvECpWi7Qq5h9e
TrKPCfiEJumwmpQwTC4IE3lmLR07r2BLU646GMTHgJauXbi8jyBTFfVHkC5x
84MOeng8li5jCLbquokFYSjo2FIG96Jtvb0Z2PusXOzYCaba/ZJQnW7oPtW/
wQSX0NX+KIoGJs34X8FFZd4TUN7SQf9C3oVAIDpQiBaGhISIgIBIqfgQmZeM
+QqjO8MyiCUYVSyy+eaWFcRw3RjFK0nZyCz7UoeFsNLj8egIywWdPZ/ZvN2s
iUqsQXWYReax+CRzbdu09N+8JZ+WIAH0dVF2xFLOsufFfE22T3cC0YfU0Xl3
KnkEuBk2RXKpAlZzI2wHfbdpa9EvJcunsx6xGT3CnFw1m0ial34Y/oWekfgp
AwIP6GswAxY6Jh9pYaiRqmTvhuSsFo8bVAAILBcEeoi3aP4WR6QYqWStsSD5
5QGq8isYUHTMDl9V0HfNuo9QDPopjZLs5VHBGYqEdoYFwiu/ZdZ0mzkCUwS3
WWMDW+uBYjrmGl5XnBxqselc500vnYRR5UHzRylaI2zRdV515tWmgI0q4Bcu
tt4DYFCs+pF+8LyzKOvCP6LgjM91uI8n3VNis4a8K2ZEEMPQkmVrjAMrYgiS
LHLCJgxvyV/BY4xd8cgBHTPmEBmkX4BIF1AwJEj00F2Zg4Mx2L0t+d2FvoJJ
BJcIExEYMeZnxv7s2iwW8FOCWiUWoDcwgOfhibpAZNnZxgjNabkIB7LNYPKD
00k0WjZsJJrw+vbgaFbUEt9JsZhy+8Q4lnOCVlveQbQOskIsbMXeOSAkdLVj
HSOArBWES4fXQsG0RAkgERI4kvG+JacE/tMTN7udTbLzy0n25mf617uLawa3
Nx+vn0LcemVKFg0CtbUDg9hWvEasf7NW8zN01hRz8Vro6DrlM8GrKwJwTQGJ
J2RbOkVsHcJdov5Yp6QWm0WSMAR93LEFw7/FXxupVHgcBYn3nDV0tTXzqsm/
Muy8xnrjETCxxlLGVpTwRUWGz2MseKj0KwEFAMVlOS/lNBUWbeqvdXNP0Nyu
ReeVUdLon+QUiez8xmJTs0+oAKhz7ivoyUqxczkBINKbtxuo3t6BmaFuiBdb
d0/jeI3buX6kcIkPgpNMzJuaP7BYr3wOBaLvElYNb/BaGD8zY97ZSvxKOqsu
EWMfMop6OHWWZjDUpTh+tlKnVbSoTLDYMOPpqamNKAUJCzF6xg2Ps58b4pGA
DiRehScvaOjzvnPVIrveQHWV4JCHxzTl9JbemboagEswQ9g4g+Yi0YzELMC8
yqhDt3bs8pA51EhHlkY6wonzDoKMMc0YPgNjhhgFRHUlPNlAEnCO5KJlJy8O
X8F1O/uvmzPy3d6cfzy/+ROcN3xAWJqVIIIbNrttHbtCNAkt+N5V1TQRcltA
98FnL0Jwb5EaRZHooNh5kQ08Nz5Tfvu1Mf8urLtyVn2viSpN4nei2CQllFJl
ujf+YzJ4seo7d8xAmZxNoInED2xHjgFhKDxnCR6v/EFZCWfQQIH9FGOLOm+7
fmctAKiwIT0QkIXzCRDnX9fhfnPdRPG2JXvCDvBNwMRWMX6qrCVW4UFkCf8T
vkXDJoWJRgcXmZQw8hoBOCI0awiYjjgUy14Z4PJYNQVjEwNsM/NpFGyjhdb/
wiq34EWzpay9dC9sSe5y0/UiFLIGVryGDIi9be16SXxLTBsYk9we0m4EUm+V
Y0bWj30pto4Twh4x7CM8nsGPAFovtspZpKFZ3wxM3m8eB2tR4cM5YX5HQINd
yQmdIy2I/tRgy7ek0u5JEjoyuBZAwlZT8lAquD6dQAhSXlX2r5a23v6rgCWb
HAANh9ObO1cHfKChKDpguF9Qe4ijYQ04UDYRfGpzx8bQ3TFYIrY5rwuHQBHN
UOa7oBjqIghu1ByEtgV67oAFk8Yus1OW8DYJc6okse8AN5oHWpD55BgeYlXF
Jsd+RNsTUCJyCt962Onfpd0RpgPBxp7HItunBYkqMSyQMqfaQBJG8aTG3EtU
Y3DFbibCvqQZPZLDUafMpTbhXdnB6iKP8YGIB/MgzsXD44I/+p5KLHuxaexl
HMkZ+vPRADIPuJLDTOIhQ20TA0GuJgKyECPCWu6JZ7qGgZWGS7yN2Spp6yar
GoJ0LRAUXA/a3mbd1BK0FSgw0DkPD37RpP6Duh4GkZgObOSjVgL7wy32zOvD
jDG+RYOfxVD3Djl48wFTEgIoC8EBhEFKjSgIcljDlewBueXz3XCvj8xMNKxA
Z0liCNdIfEWmEjCjDqDgzUi2T1mAlc0uK6ormKxHB9HIceAosyhdVWTeZWgR
qEYw3Xv9nQvTs6/LOCBGFn1agdwABDHvOMyNs8T+y6aYCFTaH4HGZsKpqquv
MFmwFcdcxLEsNVPAOPU922w+7N3oNi2QwDkitF91hISGPupDxp/F/K/WJ+G7
RETv+TjijCJanOibXhLptsI4No85gU+c05g33xxEbRV/I3n7XIdw01fw/JKs
tuNoXVknKBHLjOi0i5E+CBhtTkMX4kyATXJy7lQoQwQ+9c0GsDPLzrwbB/tG
TjLMaKnAW8FHFHX20BgXej+YI6ZxTkaa5YoMVymQjfgDtrVX8B1h444QxeSN
ang6Jljm3DNHIJ4RRuk5GBJTGuOwAAvUBHEcID78V71VoARB5zq4EUKxGGvq
RtzkJEAQkbpGJNQXWuyBv3T4VdfwjgYbwjhEUqQSdVQfoEXCkMws+6Jzt23q
GJkexBOZqxJSzMzlONaLM7J+k9DJtK1S/f01PDIvEa0POPrEE+BAUarglcrL
4qamFIgxTZajJIGlOkzzAx4powaGlREUsO0t+5l3bMFxYnW6LIl9nuYomuES
pYfHGr8f809y0glYV5wAKnH4YGOrNN9kxv4CGYqggYPnOE6EaCrXKdNISolI
n3iTQ2/Q1eJUqs8WArSeIVgiU/dTxNIIMt/xrYPXGFhuJMPnY8BhfpRMjmuB
s5lGJdLMMBthUeLG3qGYg7dDZK4lBaqBIknVbBn/IfFWC/ZocvLFIQMMmd03
MsQdnSdpg37Zsh9j5YCj60BjzqAS4cwQYNiTNk/DBKPzL4XTdKWhEA5bMYmv
CRephaV49AXjP8rEvnqcINFh6NzJwGvnrZqokAcLYXK1QA+qN/YsGDHuywFa
MuxQENEBRpKkoCZIYzKQ0xkgCmKqQFISEkpeYM1lgBUFKiIxFKgqQHFT+7gt
APY4PMob4AQEJuicG4ML1vA+cNtEwGXUNMfHaZ+f8HBAdF4lcWiXaAoHj6nE
w5VLRCqYHnQIMqzYe1YWQByhhAlnTOAtb0RvSMiTmAg5PHXHFCtyjFbfG8sS
j6Iob6JGb5DwE1QRd0kEG55cQipbFLz3Pak9b9L01CS5Sm/SERhk9DhsEBJ7
8DMnabzLJ5USYkhNh7oRHeeFh/E7NnHs5AWCRJcP7ycagSszaaMmdbL/zW9+
6bykjKmH7ankagyPFeKOsgk5507xfiqZRNJfBZvUBFH7DXmZ2aM46iO2X1JH
I3GbRLbqu7Jt6pXm/gSNJrAzOV0lgXJizvrAc+NA7XV24aD4C4ak6VZ8RULW
oW7EB2DIYPVcDKQp5DxkrmwtJYjBGkadPRFPWOWRFCIySHes9iWJ4t003jav
l/byxqH6AhE6MhvRBCLxg/zUveUNpFYLcCkpqQh6oOwksiG8zfFSmJuUvRBU
SgJxXCokaauIP8SjqIc5ZnVXTYx77eJ6VJR4JTlvFE4MAiJJAirhU6TLmIF8
vQ5JLVlzx26O+7a2omnTbHbqBIiEc2GXxyFY/vWnm0tOZQnuWpLupPfZ4xFP
SCM9Eub1MeeJWgpvmfghCVMontnGALXGGtKsBWZFgpEjvHcNp+39eLvpNnoh
XVfQBFLE45WHYZVfan5Fi8Bg6pIcLfTGcItQF6opmMRgDSPmPwhwRBtemdPp
0WE1G+CW0YARM0ieN9uS7/yEkardSvntU7JC9AZXhoM4egqjXbPHu4BKDs4A
QptQm/gRnONzbXtWgFhxmES4h7Bi03rc5h8C4DO0TA43CWIhWRoa/dSWK3wY
iBN2uXLM0yuaSP1uk5bi8JYmqlXzdgPlHmLcyigqfDZNAHnSz8y1RIF3ucPD
h+gmDwK1KT4I8UtEr+55vL9vyvwrR405+JZ4aG9twIYIa3eK0JlbOcAcKkzm
m7IS1lVdLUq2ZsWxK8scxYjx3Ag392G2lNKi+GHaDWzKTvwiVLQwMsLB2LZt
7qttrFNTLk95umjM/pDLDyMSCTDSYgV2oCTqTjZIpuUoCa1z3boox+zFlrHG
Ukpbuh+FPzjYQ9Zd8mWSJRZEoGUvvnBluBq1IL76+yIGGo05ZX4V7//hYZzv
+T4Zx/KA0xAl3BO13DWQII4KKXM3TJMwnbhEGj62KYAB9kgsNSIhJErcKQEM
GiurfAnampZkSZmFQLNi57T6kI6ocvk4Bg5G7RlJcgiKjmgqpTdpxZ28ORgt
5PxFBLl21O6N4yYlfVBXNWnWnpMBZoyVdiKH8HWGoKFTE0bIrAfunXBMZ03I
seyWrkgQ4CI7v/Q5rnRlEtW03vnetAYVWtm87EcJINWg820PlvxApKExJmGg
SE3vjdGhiTFiHO8d2U0dz2uWfQnJusnwHFNTeH55d2JY6s6w+ZpEmfzyq/dv
j5+fPCePXEs5ikHymx+92a6dJFpojOceeoSqkOYr9BahIRh83aytkNfYTguY
6M5pZSt9GAaE48mHkEaK2Sx0/bbiZ5UP1VfkTiBV8NOPzE3eSzCJ4GVPaFen
Hy8vkJR88ezw6Pv3p6yKUITORycFU4MXrpXoR8dw4/EkveXz+qEYLYEvUpPr
a3nU4+usKJohK+HR88soMMorNLBk4v2BhjIfBWDeJkMNbsqe7TFt7eLs1+nl
1eebz28/f7z+3bvP57OjQ/rn6OTgb+iGomOdHR8e408vjo9o86qi3tuq07KY
QZwHYJ8TEY9+5p8ecYqgacvbsma3yGOWhRRagGd+vjo7vT7jit0XoK/k0ryW
MFxNJBHxkZjFGNYfv5y/xVD4LwZ6dXh4SGvNMlmFL+NB2WVa4m6lSApFidmT
XchNPg064jjM0C03vRw8lx2RoTLQ5C1XoiQB+MSjiymVGtpJ+hc0/E3+B6lC
jj8nETFW7UoPZD9oeSXywZq2D5w80FxNpylPNNJ9vJ4YyW/AOwzoX3LuJIpq
cTX65XlDCZuTL99pxA+vK9YyPAUZLh6DBXeIxTQu1QkmDJPG+hfhCvKk66JZ
hRKAsIopPbVh7uCydUw9lXnCgoXWrohBipskgWG4j8H7UIWUEt9xzgnWnUjr
JCnKiX0OByFrRcp07RCijg1mOC4jRV5wy1y98SEVNi5NndQ96VKM4XgJPYti
X+hM3i67Weqy0VBMPXHKUHLbu9W6H4QlI+DSuAPwQbPpYztDIKyPBk/03Dhk
z3CMDF0rNf8x2sz+heaVfPE3QY5twriD+LfAGV9os25JX3JGjI9TT1JrQFl3
lT77voNwhT8gKLeS4dRaPCaIrxzSJXCuNCku9PFVHwPSEmx92gdXtpq6CnX1
2rpToUsrxhwY4a3jmoARQryIIeuP3Ib9pREsmR2c+C1HceDM6zEMBuIwEiow
tIqQ5W1BWAYpy02/w9XmKqgUkRWc1QacWXPFL2HhknRjeEGL+4BLN+2a4SgO
g/sIUWG22LTMIBx0E87QAFXWIyojHor5VTktLCcwcCzgnew5XwR5uJUmiZYx
ZurWFmWzzPtSvVfegftYPyJ7yGNU/HK5UC2OLd9qRKHb5yLHOltUF966NibQ
Oa7hIzhEsXtba3RBJ5sImaTW2DCnSQ4J3Y2Yy4cufwPPpwg5nCirApNSYOCy
cvI+2QlrgII0TS9dZfPmdtMNotGTQdhG+wOqrjGK5e6k+JvBARmWehoiPjsi
nED5mArh/DVpX9BUg7/ycefDOL4EeVDTp+AlAVMLyMddtF1daAcgn5Q1qHjN
HPpOUpKwEp0JLMYfr+jNvBvFJe1O+w074vyCV5ts01akdlHD03u4+MPESRoL
8IFuTz9o7jKp4cH6uG7R1l0F7sXRVZyoWu0tqNiBah8+Xf9ihjVztXpaokc1
lcvF1d1SitQExSYdC6GpKoY8hxWxSeIvTWLEQoB4au6bh9kcsB+0gih+QFWw
gqYYiY35w1IAL43lIxAo8bUcgVQ/txxqQTM6EQAGH6+NLSL4c3AMg2hmnJjR
8X3zFs/AtQdaCou1Afn41DCdpgSLE0MM6mhtGvd+BHNNK/hVckjjjF2bOMTe
floWuX+4tpHdZvzXsjYS4gwJ5wQEBOy1bkA6KF/tZ8MxBlJwwSLnGs2YTYNb
x6wy8BpaH4+2aWhmUBlvBqnnUCAN0MPGDuU7d15LaBk440K/50Tzmp1iLo1K
+dDFWeJ9DRwD920q0k2+wYdB2A8VW+g1527QTzeX3Ar67JgdAXayHh7Eg+JV
XZPvgwfP+blnxydH+IDTJi1mU3iqFdU+tAsN5Uu+7ArxT+2JJY+8N2hEPhBc
vrZlq+hSynYIukthm+hGLi0FgwGG2bYtcbShEA1MOoxphiAP5hDbEDqZ486D
P0kCkFelUzPCFf2YIDCrNywySTeI18awacY53pA/iYWBZhTNPr/M3hy/+XLa
edrEiXRQnc+DNdnVROpjTahiwkDDfevr6oRCSSDyw4Yn9kCqovV6DdpWDcdu
ySD3jSHuT1PBPSTOZJfFsoMRM/eN0Ta5TR2T3hK9AlfwdhmXc0sgh7G5zrZ1
aYkMBERieHbQUD0s5PG7E4cVKwsfSXhelSfnJ5GAIten8HXlTkBqm5Swqfnb
lVdfcuDtGJBwaI/k0KDPWw2yJkhyMV6cJsydPTn95bJ7Clq+K4kpidIQqHfn
p5/Obs6upPb62TNuteQYd2EVremyY/XGqIDhtN6q6TZ+ZB8F6sad9Elhhk/B
YllJ60DI0ZoCXpf3hhYoVAuF7MlxDCOZMWyV1ASKS8O+lmop1DvsFjEFHUk8
fVdKxl4qirkiiBWuSWKdxGpJ5WYiY8q22gWTZoxDMlj816QqQ4zaD5aq2UFE
fhPcJZKm4TY2KrJ7jsqys4M4VUvIIcTzYm8AdAOhNozf9jmwwG0Xq3AxxRjX
SIIkfZw2w+prN0WV6su0/L33daqmqW8bBg9seTotWA9FBt2WeO8bbANmmH44
O313diXt3a+ex3gUOU7oNx6Eo8Sx8dPK+JMUY2rnYXTRMYYLuDcg3zNcWIKi
o3fSWH7y8hWsDiJbPpxFr/uA+6i7o0ZfEbsYoQ7C141FxpOnMq/vpR5Z4KEl
E1tVc0SttHVIDL7Uu4YIfPYEyY0YejyZHc+OOUJKAyP6qJIVBkvn4A0KW6tn
ocXfnq11YWComGfhxL5rg1bCGzwSTFdZ5wpxWUvW0ptRylMxIBwU5opA8h1n
4GjDuBumsFvSS/EKGRCcmQaUQ/etJQ3BfW7cGY1gtoYseA0qN4OrBATb/JNT
H3YwGRRJw7PwPg0Pjjmt98V4ILbzHCej8VBT2Xpj7wl3jmQ/bKaPxKbXddAf
cjdojUwruX5QP8WJQKONRvOQhqvcHsjoY/FwLcl/aeB0hkbEplbaQIkbdqcS
q4SyHilSBTmVQ33gUGANwxD+yGvIHG0VNDgrG79Lpo/iG8iteZy9bQLqJr/m
Jno9D4+lnd5HoQg756EXdM/VDVoqu1IE+Oco5n95otWHT7n3c+68fsEOWlVJ
wekUMxq92+iIzRhMJY4ZsKMrDDNlND6+5XFQWSJgHQ7CfS1oQbqUv7pUH7Fj
EsMSGml3yEjGa+Au2Ub96EYVKdLSDIc0sgevI3Rbpj1R4SokE0rfd59Lc9EM
5JBB0LxyvLVCY1ATIQbK2Xw73Y6FrTT7H61r0oyM4lwp8eesukasyn/s3kah
ZNdLWLh0IGRNzutMrF7XTwzipeIkgbkHoGtnbVJ2AU2uJa2qyaVIL7VNaf3U
vmjAl7CFpW33rJ5EzvARafAOPKGczlVnrdzT0boBDTYCD96gkGKnbK11e8JA
mmQVl2hPG0hyBQg3W+56XR4dZglS/P793zKxOdG38+b4vOakNjPqO+1j5QPA
RnarX1V6JTrS+IB8TO4j1hp2ahQrhSwqA7OiQC+RqHar3XohSjRLDKOaRb0e
6vt3IyacG4t1zTQfN2ydJ3/hlmKh7tq1sWw09Bp3HBexedt0nWJTuSSC6xZw
8dq4WiHe5cBdFTCqcicOjvdL8ObY2PNUkXhJrYnl8lddKFNg6ap1drsBB2sy
nBEfVPmgmx0sB9v2g+MQ2fId/Jpcm55f/HJ6dX56caMY7NUrZZFI4VezZ9qp
ceTdiLkwa4gNGN/czPjDU1ldGe2+1KSEkxb4AaqacMVKTg5UKNCI9YPx0Mh8
KyNwzFD9Fx6pH9a/jcrzh+ERqRuAzyW+pjbUDFrShqSTtTHy311ViN/stLds
Bmcu5bF85vG8EmJxFU1iPcQRMAFWMIBjOaqnkUH2HngSrXry8KA53O9PY+jR
g6VU++V8pZEmeYaSostmRHa5hwRJCX1eSbueXr4FaeXog2cPCc5LiZ1Jc/u/
qUp8M3yYM6aKHx5O10gSld8I69DLI65G1GmEEHGWCPVL6FM1HN/fAoJdpgkI
Y67Qa+i93MTK+L4Qr+mSxIUb9avTuVU6ukkYNr1cJ6RfpLXxNyfTFALDip3Q
IhfRcyIezSUSUmm3677hdlgy6n3jW4Yico2Tmt/aYVkvqo3c+yW3Vg2jJzgj
tdbo+vv95enNh+n1+c8Xpx9Ft/z000uO7XUA6QTtVpzaSwwvjY21+qpmnM8t
KidNhIs4PybmkHajRrN0JJ+z5R5Mx+wRiy12Sgzi+BIc18tiY/IzonLEppKm
n+GSE4TrEWSnLThJT83j7CxExt+TDMGRQyV2WQm7W+38+ecaNAnIT+hIdCht
JfICQNJOToGVWj9fuJ9eCUKL+qUMQ+JENAOweyGAjztAXFMI/dXnQtiBNYn2
0eilfhqjHdKPEuhQLqR80cdckESIJsSgjD3voz7luHjIVUC7IMKZZC/SWrGQ
cGBdBe/C4AJi4hYp3fBnwJ1fYeuM2CLtCn+nFzbB1+LxOrm7iVVfXLxh0x7u
ijxP8384EFh2mDM5Dqnu2fQNOC73+QjHp7Q1Eizo/PTJ1DCz8hb3ROsW/Nnb
weLZiISH9RnucNEuWkxq/KTM71hreGUnJ0Y6vlY+96kDQdxAm+TMommX42qZ
v84m4wKsm+n1Lyx3L14+e6mogt0t34vLljp0zJlm0+f+LjBk8Gys6a6THY22
z/slJ7sXooUVooVq39Kk1SKUO6f5ufCuv3Sn9xYRN9Iqt3DdCkeyQz8MKM8B
Bc5p7OugiHcIDConExnw3jnrZL2pic7I0dpFgco0O4dDkxm+a2ji+YV/xnAe
zYYMVyeeINc3xXjO+CpLs/Sb1TkVSnPoqJj4ayomvi1Fu8MHLBoq872CCUOp
ngq6ZiEC4CFuIlie3p3KnI2lvBEadM75Gqx3n06vhN2ev1SEazQ/NSVrOb3y
ioQt1fOTQ3V9smt/hc1b7RcVYhnzCZ5eBCuayPR1aTETHK798Rwu56UXo5l4
vU9oqp1vuf8SVQUdx3gRX1hp/UFyp9qKfBRcDIbDRSgey1rZIsbWkwwiFzZ+
61nStYG4drcoQJA+OFWLg7JCcGOcrVkTgSXWPVrg6A5TXaUaeKRLSOFDcmKO
1pdoJ3eE70fuwXHktuJIK2MDGvDxmd0YkoYPFVyMYFC0WVy0JQGWGFsZrEK0
gpHCh76Fc6d7ipmLcMwR2qRhO7n2mf390IrE2TPt5vO3mAxuG/OeScJV8fIu
ve8CYSeyjZK7S/ao9xCN6vt1n1rHcjNM3Pi0anBjJuNrRveVVGoJTooP/LVP
whixbsH3XQxwSFKEoz3BZnhUse0/NgWwDfk5XC704uTVCZeHDm4bIM6guf3F
QekFt3zfkP0KbLFMx0ccmCVo2IEYOmRXEsZ6eMDXBngNQW7G6Y52GN74Jff3
1Q2rUyd9THjN37IsuC/JtiO/rpdm6FjWOznJDUrztnQL4shNsVVsGMopfPUV
Jtq5OANVGFHFhztCtSaV1uI73y6ujfnsL2VFoJzrouZcpcHRcMUYae4BfHLl
umaDCPgVCQOuaqfXOvPk6op/eBpaYH1w73R0+aG0xLDMb0m/8+LS8LaZk/Vi
5f5PurLnos3K5NaF5M6SmcGx+U6qCbNX1dhCr+jzJLn5rxuW6laSE5tBB04s
sIAqR+TeX+swYdjKGZ5NKA1yZFA4uHmJW9m22fvWrhwbYlijy/fMzceHhIgM
J/53+hAk7aAFAtzDgRuA/NHVBZomY4UjJ2e0mieULugxwP5dXd386ZJLtZ/9
9OqF5sCSy3zGl7CECgEdw0s/ql6Q7RcYEBrYlI8YChrJKDKaj14m44AI/vfd
aZOW2kENWxwpByAbZOoGOUoB2QxZuf1dgtU/vjPHhOgCnNLQzl2EUugyvYY9
dNR5U663egWv92zP8nnbiePOxfz3pRQkS3FEUMrj9Rn4IUBl+XJTf/UcxL9g
jcDBqEImwcEBx4jdi9mRz+Eecd0N0y1qeg4gD9/uBrXHySzy8SRgUNYrZlPz
hadBz3jFlvRKPPdLiFHkS7E5vptFGldolPNLTfvVwnYb1EZ2WhZM3pldk35h
zho0qEwMpm3j9akclUC6Q28mv7w7GTSxEFLacHSGU4Bw9blP5BjoGPgfF61y
GbVe4VXWvo+uT2qOcQUt4JXInL99UpUFWmCUJwfBMm/C204u2Q8X6QYODNW6
7G3ILRUxq51eoKmKHl4iMfzVuG3Bwz9fLsK3GIciJZGiUr6WYHjRlu/G4QXW
C1JQo3e1NK0PZcthqnpLnsHaZc3upbnaRaD5W9/Fo03tx8fPD55lj/KKyJud
PfLXYkrFsbAG0VPO8PDVy5ew8lK4yg+MmlECCQX0450XSO2bsM4uflHINtkY
35sBhVEivMU1iwxbdFRaHvdt4GSIbEgic3Ytx818T7CH508FprMQsXQvVUvz
YIPyleF4acLoyfHzQxrKDPYrvWej8lBfqp1Wo2obPB/N8MDDtVdcvj9UaHIP
WMqR6oWNlhkC09AmmmXlXgAtCEpqeOKSvG7jfrl9CF8xGxQ1vszg1hDV0hol
mAthCVZCg7G74RdXyI3Hq+gG2s5IvLyITVne7eUvgVlXmy7B/GlEAJ9rRj6J
bvuLhmHYSGddEUuR+jitHJxXHNrp3XMY0+MjZErkDyf8hxfQw3xi9J7vkxnc
8RxKAFG/WSBKqAfEt/PItVriTy1EPkMLhEY2axorIyHkSivXGq2oCwrd3zjL
lUa9IqkI0Sca0UoLCmUkIgw2aBj81GkDYax9QzNOuAVGM1QQM9otCepX1zPo
xDX6XGHLX9SxmnOpDavquS0GGnZ0JVboOfWKF6ku13J0FgU4yfdf7BRLeLiU
XHlDyFw663TYgJyJsrj02Fh/02u4p4ZLRIAr0vt4M72Pl2+1B9YQgvni2euL
T5eaAvM9+oN6Pmn59NZQDci1eOcXyqifOKDCMY9gTJ5g4KeMGOmHuyNw2NHR
T8BvPvmpok0H2zl2r7jxBF4omB3MVRi9hMEXdq3W0oiQE4RMVLv36yWDysSv
seZ4mdSoy9Xvg5bm73mYaYO4lODiC4fIkyL7lS+lRF8mldHA7uT6raQ3T86Y
fSff/OIjfwiU01J4npA7Pp5kxzm/+ixDzQpfq0KKo6n4a11updMcuP2b5c6f
e98/FDuW9bsyOq6mSMVhkKUGQ2hzUyISWlbEeZ7RRTE0/+BlzqFyukx8KT53
5Zybt5f70SR9wN+M8pbLpcm6ISMbr3kMCGrwbQJQ2sa3UKnQhsxFuFMMC+MK
AL2Pa4pJfAPp0fOfDo4PT16+PDqZ8X+fPQ+mKcYbV+n3a2Gd/EVeUmJ3jCZi
vqqulstxvVNhGi43I0TZad+Gr0MYfg0YO/innRlOIrd6cWb2ttUbXPTbWfyx
DTOjrBNiP1m1NVpzzBKptad9E1roQ7pH74zkmUUdJ71s4KBYhsMtQlxl1ZYd
mgd2Vet7QIfPBC75ON9/ltgkJ9hjA4vvf2M/YM8dVoPSwUG9mDZhyAUoKFdP
7B5pcr00cbiBYf2ixVccAUngigfCDiB2XLS/DFS/HUjdQ3buwq3nzMgfrwnz
w9XgkkLpyw4x1Se4mp0J8PH66Fi+M+r5CZFAay+H94RKhsKa9Dp2lL3O/xb6
qDouIUSoXp2HcIdVeh2HVNLTyvZOkyQJdu9jHt0VO+pAMuaXPc9JH052NDsO
SSK0Fwame/QB39aCO543vbTNagUmLiTV8Z6g9+jpo6zLl058Wt6S7dRJ9V+D
46Hv6D69mQk2MfQjcBuAD735HrZwqafOG5pWrVw4YA3KDwhk3u1+Y4P/Cg4u
gEQbhKoa/90fUms4vCxxXDPBohMvGNPvEAL5gu4s+Ypa/i4eKInkmxiRvgVT
CLWfGWWsZxLTZ8ayc/RhAnaAoHuPVa5dxbQhjhIuqecN8FdZKkbjs7m+OPdc
PCXCs747PDnh+255MWUo6De4ZwpXivZDj8h5tpNqIL4NXfjcjZhMjMGMv3vT
BB7iUrB4E8Ggcz1ICgP9gSvi77qSMhJfx4wlD67ccMHJSroF8K2e7GJwzYME
B2KMwYSiRV+GKKWlzSIJPXJlIhEXQ/3gXgFGh6GNnH17mFP+qkFLOI57Q/Ar
vgqukd0YfgwOmDaNwwPT4BhC8MGD8V/oFA2oXgZQSCUlF9Lb2kSvzn1zdGjI
CfpoOdZe6q3JsXBsqG7UySdPD06yETdytzNZv5KsDyguNNBFtn14oAl96Pk0
3GfO4U7z8FowmCt+92hBaNU9Qvi4cS1HU84IqgLn/0oj4xs07Vfog09l+zeb
/ef/+7/Lyt0TV0+ys6okvf7RIWDP3+Z40fBVoUu7kmsX36AEJyOtvlrhgjuO
mKeNAVynyZEH1QaDRNjM/H8A7ffEMHkAAA==
</back>
</rfc> </rfc>
 End of changes. 79 change blocks. 
1513 lines changed or deleted 616 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/