rfc8768xml2.original.xml   rfc8768.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc tocompact="yes"?> category="std"
<?rfc tocdepth="4"?> docName="draft-ietf-core-hop-limit-07"
<?rfc tocindent="yes"?> number="8768"
<?rfc symrefs="yes"?> ipr="trust200902"
<?rfc sortrefs="yes"?> obsoletes=""
<?rfc comments="yes"?> updates=""
<?rfc inline="yes"?> submissionType="IETF"
<?rfc compact="yes"?> consensus="true"
<?rfc subcompact="no"?> xml:lang="en"
<rfc category="std" docName="draft-ietf-core-hop-limit-07" ipr="trust200902"> tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true"
version="3">
<front> <front>
<title abbrev="CoAP Hop Limit Option">Constrained Application Protocol <title abbrev="CoAP Hop-Limit Option">Constrained Application Protocol
(CoAP) Hop-Limit Option</title> (CoAP) Hop-Limit Option</title>
<seriesInfo name="RFC" value="8768"/>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street>
<city>Rennes</city> <city>Rennes</city>
<region></region>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="McAfee">McAfee, Inc.</organization> <organization abbrev="McAfee">McAfee, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Embassy Golf Link Business Park</street> <street>Embassy Golf Link Business Park</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560071</code> <code>560071</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jon Shallow" initials="J." surname="Shallow"> <author fullname="Jon Shallow" initials="J." surname="Shallow">
<organization></organization> <organization/>
<address> <address>
<postal> <postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>supjps-ietf@jpshallow.com</email> <email>supjps-ietf@jpshallow.com</email>
</address> </address>
</author> </author>
<date month="March" year="2020"/>
<date />
<workgroup>CORE</workgroup> <workgroup>CORE</workgroup>
<keyword>security</keyword> <keyword>security</keyword>
<keyword>mitigation</keyword> <keyword>mitigation</keyword>
<keyword>service delivery</keyword> <keyword>service delivery</keyword>
<keyword>connectivity</keyword> <keyword>connectivity</keyword>
<keyword>anti-DDoS</keyword> <keyword>anti-DDoS</keyword>
<keyword>automation</keyword> <keyword>automation</keyword>
<keyword>cooperation</keyword> <keyword>cooperation</keyword>
<keyword>Resilience</keyword> <keyword>Resilience</keyword>
<keyword>Filtering</keyword> <keyword>Filtering</keyword>
<keyword>Security Center</keyword> <keyword>Security Center</keyword>
<keyword>Mitigator</keyword> <keyword>Mitigator</keyword>
<keyword>Scrubbing</keyword> <keyword>Scrubbing</keyword>
<keyword>dynamic service protection</keyword> <keyword>dynamic service protection</keyword>
<keyword>dynamic mitigation</keyword> <keyword>dynamic mitigation</keyword>
<abstract> <abstract>
<t>The presence of Constrained Application Protocol (CoAP) proxies may <t>The presence of Constrained Application Protocol (CoAP) proxies may
lead to infinite forwarding loops, which is undesirable. To prevent and lead to infinite forwarding loops, which is undesirable. To prevent and
detect such loops, this document specifies the Hop-Limit CoAP detect such loops, this document specifies the Hop-Limit CoAP
option.</t> option.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>More and more applications are using the Constrained Application <t>More and more applications are using the Constrained Application
Protocol (CoAP) <xref target="RFC7252"></xref> as a communication Protocol (CoAP) <xref target="RFC7252" format="default"/> as a communicati
protocol between application agents. For example, <xref on
target="I-D.ietf-dots-signal-channel"></xref> specifies how CoAP is used protocol between application agents. For example, <xref target="I-D.ietf-d
ots-signal-channel" format="default"/> specifies how CoAP is used
as a signaling protocol between domains under distributed as a signaling protocol between domains under distributed
denial-of-service (DDoS) attacks and DDoS mitigation providers. In such denial-of-service (DDoS) attacks and DDoS mitigation providers. In such
contexts, a CoAP client can communicate directly with a server or contexts, a CoAP client can communicate directly with a server or
indirectly via proxies.</t> indirectly via proxies.</t>
<t>When multiple proxies are involved, infinite forwarding loops may be <t>When multiple proxies are involved, infinite forwarding loops may be
experienced (e.g., routing misconfiguration, policy conflicts). To experienced (e.g., routing misconfiguration, policy conflicts). To
prevent such loops, this document defines a new CoAP option, called prevent such loops, this document defines a new CoAP option, called
Hop-Limit (<xref target="spec"></xref>). Also, the document defines a Hop-Limit (<xref target="spec" format="default"/>). Also, the document def
new CoAP Response Code (<xref target="code"></xref>) to report loops ines a
new CoAP Response Code (<xref target="code" format="default"/>) to report
loops
together with relevant diagnostic information to ease troubleshooting together with relevant diagnostic information to ease troubleshooting
(<xref target="debug"></xref>).</t> (<xref target="debug" format="default"/>).</t>
<section numbered="true" toc="default">
<section title="Intended Usage"> <name>Intended Usage</name>
<t>The Hop-Limit option was originally designed for a specific use <t>The Hop-Limit option was originally designed for a specific use
case <xref target="I-D.ietf-dots-signal-channel"></xref>. However, its case <xref target="I-D.ietf-dots-signal-channel" format="default"/>. How
intended usage is general: <list style="empty"> ever, its
<t>New CoAP proxies MUST implement this option and have it enabled intended usage is general: </t>
by default.</t>
</list></t>
<ul empty="true" spacing="normal">
<li>New CoAP proxies <bcp14>MUST</bcp14> implement this option and hav
e it enabled
by default.</li>
</ul>
<t>Note that this means that a server that receives requests both via <t>Note that this means that a server that receives requests both via
proxies and directly from clients may see otherwise identical requests proxies and directly from clients may see otherwise identical requests
with and without the Hop-Limit option included; servers with internal with and without the Hop-Limit option included; servers with internal
caching will therefore also want to implement this option, since caching will therefore also want to implement this option, since
understanding the Hop-Limit option will improve caching understanding the Hop-Limit option will improve caching
efficiency.</t> efficiency.</t>
</section> </section>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<section anchor="notation" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
only when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>Readers should be familiar with the terms and concepts defined in <t>Readers should be familiar with the terms and concepts defined in
<xref target="RFC7252"></xref>.</t> <xref target="RFC7252" format="default"/>.</t>
</section> </section>
<section anchor="spec" numbered="true" toc="default">
<section anchor="spec" title="Hop-Limit Option"> <name>Hop-Limit Option</name>
<t>The properties of the Hop-Limit option are shown in Table 1. The <t>The properties of the Hop-Limit option are shown in <xref target="tab-o
formatting of this table follows the one used in Table 4 of <xref ption-props" format="default"/>. The
target="RFC7252"></xref> (Section 5.10). The C, U, N, and R columns formatting of this table follows the one used in Table 4 of
<xref target="RFC7252" section="5.10" sectionFormat="parens" format="defau
lt"/>. The C, U, N, and R columns
indicate the properties Critical, Unsafe, NoCacheKey, and Repeatable indicate the properties Critical, Unsafe, NoCacheKey, and Repeatable
defined in Section 5.4 of <xref target="RFC7252"></xref>. None of these defined in <xref target="RFC7252" section="5.4" sectionFormat="of" format= "default"/>. None of these
properties is marked for the Hop-Limit option.</t> properties is marked for the Hop-Limit option.</t>
<t><figure align="center"> <table anchor="tab-option-props">
<artwork align="center"><![CDATA[+--------+---+---+---+---+----------- <name>CoAP Hop-Limit Option Properties</name>
+--------+--------+---------+ <thead>
| Number | C | U | N | R | Name | Format | Length | Default | <tr>
+--------+---+---+---+---+-----------+--------+--------+---------+ <th>Number</th>
| TBA2 | | | | | Hop-Limit | uint | 1 | 16 | <th>C</th>
+--------+---+---+---+---+-----------+--------+--------+---------+ <th>U</th>
<th>N</th>
Table 1: CoAP Hop-Limit Option Properties]]></artwork> <th>R</th>
</figure></t> <th>Name</th>
<th>Format</th>
<t>The Hop-Limit option (<xref target="option"></xref>) is an elective <th>Length</th>
<th>Default</th>
</tr>
</thead>
<tbody>
<tr>
<td>16</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>Hop-Limit</td>
<td>uint</td>
<td>1</td>
<td>16</td>
</tr>
</tbody>
</table>
<t>The Hop-Limit option (<xref target="option" format="default"/>) is an e
lective
option used to detect and prevent infinite loops of CoAP requests when option used to detect and prevent infinite loops of CoAP requests when
proxies are involved. The option is not repeatable. Therefore, any proxies are involved. The option is not repeatable. Therefore, any
request carrying multiple Hop-Limit options MUST be handled following request carrying multiple Hop-Limit options <bcp14>MUST</bcp14> be handled
the procedure specified in Section 5.4.5 of <xref following
target="RFC7252"></xref>.</t> the procedure specified in <xref target="RFC7252" section="5.4.5" sectionF
ormat="of" format="default"/>.</t>
<t>The value of the Hop-Limit option is encoded as an unsigned integer <t>The value of the Hop-Limit option is encoded as an unsigned integer
(see Section 3.2 of <xref target="RFC7252"></xref>). This value MUST be (see <xref target="RFC7252" section="3.2" sectionFormat="of" format="defau lt"/>). This value <bcp14>MUST</bcp14> be
between 1 and 255 inclusive. CoAP requests received with a Hop-Limit between 1 and 255 inclusive. CoAP requests received with a Hop-Limit
option set to '0' or greater than '255' MUST be rejected by a CoAP option set to '0' or greater than '255' <bcp14>MUST</bcp14> be rejected by a CoAP
server/proxy using 4.00 (Bad Request).</t> server/proxy using 4.00 (Bad Request).</t>
<t>The Hop-Limit option is safe to forward. That is, a CoAP proxy that <t>The Hop-Limit option is safe to forward. That is, a CoAP proxy that
does not understand the Hop-Limit option should forward it on. The does not understand the Hop-Limit option should forward it on. The
option is also part of the cache key. As such, a CoAP proxy that does option is also part of the cache key. As such, a CoAP proxy that does
not understand the Hop-Limit option must follow the recommendations in not understand the Hop-Limit option must follow the recommendations in
Section 5.7.1 of <xref target="RFC7252"></xref> for caching. Note that <xref target="RFC7252" section="5.7.1" sectionFormat="of" format="default" /> for caching. Note that
loops that involve only such proxies will not be detected. Nevertheless, loops that involve only such proxies will not be detected. Nevertheless,
the presence of such proxies will not prevent infinite loop detection if the presence of such proxies will not prevent infinite loop detection if
at least one CoAP proxy that supports the Hop-Limit option is involved at least one CoAP proxy that supports the Hop-Limit option is involved
in the loop.</t> in the loop.</t>
<t>A CoAP proxy that understands the Hop-Limit option <bcp14>SHOULD</bcp14
<t>A CoAP proxy that understands the Hop-Limit option SHOULD be > be
instructed, using a configuration parameter, to insert a Hop-Limit instructed, using a configuration parameter, to insert a Hop-Limit
option when relaying a request that does not include the Hop-Limit option when relaying a request that does not include the Hop-Limit
option.</t> option.</t>
<t>The initial Hop-Limit value should be configurable. If no initial <t>The initial Hop-Limit value should be configurable. If no initial
value is explicitly provided, the default initial Hop-Limit value of 16 value is explicitly provided, the default initial Hop-Limit value of 16
MUST be used. This value is chosen so that in the majority of cases it <bcp14>MUST</bcp14> be used. This value is chosen so that in the majority of cases, it
is sufficiently large to guarantee that a CoAP request would not be is sufficiently large to guarantee that a CoAP request would not be
dropped in networks when there were no loops, but not so large as to dropped in networks when there were no loops, but not so large as to
consume CoAP proxy resources when a loop does occur. The value is still consume CoAP proxy resources when a loop does occur. The value is still
configurable to accommodate unusual topologies. Lower values should be configurable to accommodate unusual topologies. Lower values should be
used with caution and only in networks where topologies are known by the used with caution and only in networks where topologies are known by the
CoAP client (or proxy) inserting the Hop-Limit option.</t> CoAP client (or proxy) inserting the Hop-Limit option.</t>
<t>Because forwarding errors may occur if inadequate Hop-Limit values <t>Because forwarding errors may occur if inadequate Hop-Limit values
are used, proxies at the boundaries of an administrative domain MAY be are used, proxies at the boundaries of an administrative domain <bcp14>MAY </bcp14> be
instructed to remove or rewrite the value of Hop-Limit carried in instructed to remove or rewrite the value of Hop-Limit carried in
received requests (i.e., ignore the value of Hop-Limit received in a received requests (i.e., ignore the value of Hop-Limit received in a
request). This modification should be done with caution in case request). This modification should be done with caution in case
proxy-forwarded traffic repeatedly crosses the administrative domain proxy-forwarded traffic repeatedly crosses the administrative domain
boundary in a loop rendering ineffective the efficacy of loop detection boundary in a loop, rendering ineffective the efficacy of loop detection
through the Hop-Limit option.</t> through the Hop-Limit option.</t>
<t>Otherwise, a CoAP proxy that understands the Hop-Limit option MUST <t>Otherwise, a CoAP proxy that understands the Hop-Limit option <bcp14>MU ST</bcp14>
decrement the value of the option by 1 prior to forwarding it. A CoAP decrement the value of the option by 1 prior to forwarding it. A CoAP
proxy that understands the Hop-Limit option MUST NOT use a stored TBA1 proxy that understands the Hop-Limit option <bcp14>MUST NOT</bcp14> use a stored 5.08
(Hop Limit Reached) error response unless the value of the Hop-Limit (Hop Limit Reached) error response unless the value of the Hop-Limit
option in the presented request is smaller than or equal to the value of option in the presented request is smaller than or equal to the value of
the Hop-Limit option in the request used to obtain the stored response. the Hop-Limit option in the request used to obtain the stored response.
Otherwise, the CoAP proxy follows the behavior in Section 5.6 of <xref Otherwise, the CoAP proxy follows the behavior in
target="RFC7252"></xref>.<list style="empty"> <xref target="RFC7252" section="5.6" sectionFormat="of" format="default"/>
<t>Note: If a request with a given value of Hop-Limit failed to .</t>
<ul empty="true" spacing="normal">
<li>Note: If a request with a given value of Hop-Limit failed to
reach a server because the hop limit is exhausted, then the same reach a server because the hop limit is exhausted, then the same
failure will be observed if a smaller value of the Hop-Limit option failure will be observed if a smaller value of the Hop-Limit option
is used instead.</t> is used instead.</li>
</list></t> </ul>
<t>CoAP requests <bcp14>MUST NOT</bcp14> be forwarded if the Hop-Limit opt
<t>CoAP requests MUST NOT be forwarded if the Hop-Limit option is set to ion is set to
'0' after decrement. Requests that cannot be forwarded because of '0' after decrement. Requests that cannot be forwarded because of
exhausted Hop-Limit SHOULD be logged with a TBA1 (Hop Limit Reached) exhausted Hop-Limit <bcp14>SHOULD</bcp14> be logged with a 5.08 (Hop Limit
error response sent back to the CoAP peer. It is RECOMMENDED that CoAP Reached)
error response sent back to the CoAP peer. It is <bcp14>RECOMMENDED</bcp14
> that CoAP
implementations support means to alert administrators about loop errors implementations support means to alert administrators about loop errors
so that appropriate actions are undertaken.</t> so that appropriate actions are undertaken.</t>
</section> </section>
<section anchor="debug" title="Debugging &amp; Troubleshooting"> <section anchor="debug" numbered="true" toc="default">
<name>Debugging and Troubleshooting</name>
<t>To ease debugging and troubleshooting, the CoAP proxy that detects a <t>To ease debugging and troubleshooting, the CoAP proxy that detects a
loop includes an identifier for itself in the diagnostic payload under loop includes an identifier for itself in the diagnostic payload under
the conditions detailed in Section 5.5.2 of <xref the conditions detailed in <xref target="RFC7252" section="5.5.2" sectionF
target="RFC7252"></xref>. That identifier MUST NOT include any space ormat="of" format="default"/>.
That identifier <bcp14>MUST NOT</bcp14> include any space
character (ASCII value 32). The identifier inserted by a CoAP proxy can character (ASCII value 32). The identifier inserted by a CoAP proxy can
be, for example, a proxy name (e.g., p11.example.net), proxy alias be, for example, a proxy name (e.g., p11.example.net), proxy alias
(e.g., myproxyalias), or IP address (e.g., 2001:db8::1).</t> (e.g., myproxyalias), or IP address (e.g., 2001:db8::1).</t>
<t>Each intermediate proxy involved in relaying a 5.08 (Hop Limit
<t>Each intermediate proxy involved in relaying a TBA1 (Hop Limit
Reached) error message prepends its own identifier in the diagnostic Reached) error message prepends its own identifier in the diagnostic
payload with a space character used as separator. Only one identifier payload with a space character used as separator. Only one identifier
per proxy should appear in the diagnostic payload. This approach allows per proxy should appear in the diagnostic payload.
to limit the size of the TBA1 (Hop Limit Reached) error message, ease This approach allows the limiting of the size of the 5.08 (Hop
correlation with hops count, and detect whether a proxy was involved in Limit Reached) error message, eases the correlation with hops
the forwarding of the TBA1 (Hop Limit Reached) error message. Note that count, and detects whether a proxy was involved in the forwarding
of the 5.08 (Hop Limit Reached) error message. Note that
an intermediate proxy prepends its identifier only if there is enough an intermediate proxy prepends its identifier only if there is enough
space as determined by the Path MTU (Section 4.6 of <xref space as determined by the Path MTU
target="RFC7252"></xref>). If not, an intermediate proxy forwards the (<xref target="RFC7252" section="4.6" sectionFormat="of" format="default"/
TBA1 (Hop Limit Reached) error message to the next hop without updating >).
If not, an intermediate proxy forwards the
5.08 (Hop Limit Reached) error message to the next hop without updating
the diagnostic payload.</t> the diagnostic payload.</t>
<t>An intermediate proxy <bcp14>MUST NOT</bcp14> forward a 5.08 (Hop Limit
<t>An intermediate proxy MUST NOT forward a TBA1 (Hop Limit Reached) Reached)
error message if it detects that its identifier is included in the error message if it detects that its identifier is included in the
diagnostic payload. Such messages SHOULD be logged and appropriate diagnostic payload. Such messages <bcp14>SHOULD</bcp14> be logged and appr opriate
alerts sent to the administrators.</t> alerts sent to the administrators.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="HTTP-Mapping Considerations"> <name>HTTP Mapping Considerations</name>
<t>This section focuses on the HTTP mappings specific to the CoAP <t>This section focuses on the HTTP mappings specific to the CoAP
extension specified in this document. As a reminder, the basic normative extension specified in this document. As a reminder, the basic normative
requirements on HTTP/CoAP mappings are defined in Section 10 of <xref requirements on HTTP/CoAP mappings are defined in
target="RFC7252"></xref>. The implementation guidelines for HTTP/CoAP <xref target="RFC7252" section="10" sectionFormat="of" format="default"/>.
mappings are elaborated in <xref target="RFC8075"></xref>.</t> The implementation guidelines for HTTP/CoAP
mappings are elaborated in <xref target="RFC8075" format="default"/>.</t>
<t>By default, the HTTP-to-CoAP Proxy inserts a Hop-Limit option <t>By default, the HTTP-to-CoAP Proxy inserts a Hop-Limit option
following the guidelines in <xref target="spec"></xref>. The following the guidelines in <xref target="spec" format="default"/>. The
HTTP-to-CoAP Proxy may be instructed by policy to insert a Hop-Limit HTTP-to-CoAP Proxy may be instructed by policy to insert a Hop-Limit
option only if a Via (Section 5.7.1 of <xref target="RFC7230"></xref>) option only if a Via (<xref target="RFC7230" section="5.7.1" sectionFormat
or CDN-Loop header field <xref target="RFC8586"></xref> is present in ="of" format="default"/>)
or CDN-Loop header field <xref target="RFC8586" format="default"/> is pres
ent in
the HTTP request.</t> the HTTP request.</t>
<t>The HTTP-to-CoAP Proxy uses 508 (Loop Detected) as the HTTP response <t>The HTTP-to-CoAP Proxy uses 508 (Loop Detected) as the HTTP response
status code to map TBA1 (Hop Limit Reached). Furthermore, it maps the status code to map 5.08 (Hop Limit Reached). Furthermore, it maps the
diagnostic payload of TBA1 (Hop Limit Reached) as per Section 6.6 of diagnostic payload of 5.08 (Hop Limit Reached) as per
<xref target="RFC8075"></xref>.</t> <xref target="RFC8075" section="6.6" sectionFormat="of" format="default"/>
.</t>
<t>By default, the CoAP-to-HTTP Proxy inserts a Via header field in the <t>By default, the CoAP-to-HTTP Proxy inserts a Via header field in the
HTTP request if the CoAP request includes a Hop-Limit option. The HTTP request if the CoAP request includes a Hop-Limit option. The
CoAP-to-HTTP Proxy may be instructed by policy to insert a CDN-Loop CoAP-to-HTTP Proxy may be instructed by policy to insert a CDN-Loop
header field instead of the Via header field.</t> header field instead of the Via header field.</t>
<t>The CoAP-to-HTTP Proxy maps the 508 (Loop Detected) HTTP response <t>The CoAP-to-HTTP Proxy maps the 508 (Loop Detected) HTTP response
status code to TBA1 (Hop Limit Reached). Moreover, the CoAP-to-HTTP status code to 5.08 (Hop Limit Reached). Moreover, the CoAP-to-HTTP
Proxy inserts its information following the guidelines in <xref Proxy inserts its information following the guidelines in <xref target="de
target="debug"></xref>.</t> bug" format="default"/>.</t>
<t>When both HTTP-to-CoAP and CoAP-to-HTTP proxies are involved, the <t>When both HTTP-to-CoAP and CoAP-to-HTTP proxies are involved, the
loop detection may get broken if the proxy-forwarded traffic repeatedly loop detection may break if the proxy-forwarded traffic repeatedly
crosses the HTTP-to-CoAP and CoAP-to-HTTP proxies. Nevertheless, if the crosses the HTTP-to-CoAP and CoAP-to-HTTP proxies. Nevertheless, if the
loop is within the CoAP or HTTP legs, the loop detection is still loop is within the CoAP or HTTP legs, the loop detection is still
functional.</t> functional.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t><list style="empty"> <section anchor="code" numbered="true" toc="default">
<t>Editorial Note: Please update TBA1/TBA2 statements within the <name>CoAP Response Code</name>
document with the assigned codes.</t> <t>IANA has registered the following entry in the "CoAP Response
</list></t> Codes" subregistry available at
<eref target="https://www.iana.org/assignments/core-parameters" brackets
<section anchor="code" title="CoAP Response Code"> ="angle"/>:</t>
<t>IANA is requested to add the following entry to the "CoAP Response <table anchor="tab-resp-codes">
Codes" sub-registry available at <name>CoAP Response Codes</name>
https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#r <thead>
esponse-codes:</t> <tr>
<th>Code</th>
<t><figure align="center"> <th>Description</th>
<artwork align="center"><![CDATA[+------+------------------+-------- <th>Reference</th>
---+ </tr>
| Code | Description | Reference | </thead>
+------+------------------+-----------+ <tbody>
| TBA1 | Hop Limit Reached| [RFCXXXX] | <tr>
+------+------------------+-----------+ <td>5.08</td>
<td>Hop Limit Reached</td>
Table 2: CoAP Response Codes]]></artwork> <td>RFC 8768</td>
</figure></t> </tr>
</tbody>
<t>This document suggests 5.08 as a code to be assigned for the new </table>
response code.</t>
</section> </section>
<section anchor="option" title="CoAP Option Number"> <section anchor="option" numbered="true" toc="default">
<t>IANA is requested to add the following entry to the "CoAP Option <name>CoAP Option Number</name>
Numbers" sub-registry available at <t>IANA has registered the following entry in the "CoAP Option
https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#o Numbers" subregistry available at
ption-numbers:</t> <eref target="https://www.iana.org/assignments/core-parameters" brackets
="angle"/>:</t>
<t><figure align="center"> <table anchor="tab-option-number">
<artwork align="center"><![CDATA[+--------+------------------+------ <name>CoAP Option Number</name>
-----+ <thead>
| Number | Name | Reference | <tr>
+--------+------------------+-----------+ <th>Number</th>
| TBA2 | Hop-Limit | [RFCXXXX] | <th>Name</th>
+--------+------------------+-----------+ <th>Reference</th>
</tr>
Table 3: CoAP Option Number]]></artwork> </thead>
</figure></t> <tbody>
<tr>
<t>This document suggests 16 as a value to be assigned for the new <td>16</td>
option number.</t> <td>Hop-Limit</td>
<td>RFC 8768</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>Security considerations related to CoAP proxying are discussed in <t>Security considerations related to CoAP proxying are discussed in
Section 11.2 of <xref target="RFC7252"></xref>.</t> <xref target="RFC7252" section="11.2" sectionFormat="of" format="default"/
>.</t>
<t>A CoAP endpoint can probe the topology of a network into which it is <t>A CoAP endpoint can probe the topology of a network into which it is
making requests by tweaking the value of the Hop-Limit option. Such making requests by tweaking the value of the Hop-Limit option. Such
probing is likely to fail if proxies at the boundaries of that network probing is likely to fail if proxies at the boundaries of that network
rewrite the value of Hop-Limit carried in received requests (see <xref rewrite the value of Hop-Limit carried in received requests (see <xref tar
target="spec"></xref>).</t> get="spec" format="default"/>).</t>
<t>The diagnostic payload of a 5.08 (Hop Limit Reached) error message
<t>The diagnostic payload of a TBA1 (Hop Limit Reached) error message
may leak sensitive information revealing the topology of an may leak sensitive information revealing the topology of an
administrative domain. To prevent that, a CoAP proxy that is located at administrative domain. To prevent that, a CoAP proxy that is located at
the boundary of an administrative domain MAY be instructed to strip the the boundary of an administrative domain <bcp14>MAY</bcp14> be instructed
diagnostic payload or part of it before forwarding on the TBA1 (Hop to strip the
diagnostic payload or part of it before forwarding on the 5.08 (Hop
Limit Reached) response.</t> Limit Reached) response.</t>
</section> </section>
<section anchor="ack" title="Acknowledgements">
<t>This specification was part of <xref
target="I-D.ietf-dots-signal-channel"></xref>. Many thanks to those who
reviewed DOTS specifications.</t>
<t>Thanks to Klaus Hartke, Carsten Bormann, Peter van der Stok, Jim
Schaad, Jaime Jim&eacute;nez, Roni Even, Scott Bradner, Thomas Fossati,
Radia Perlman, &Eacute;ric Vyncke, Suresh Krishnan, Roman Danyliw, Barry
Leiba, Christer Holmberg, Benjamin Kaduk, and Adam Roach for their
review and comments.</t>
<t>Carsten Bormann provided the "Intended Usage" text.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-dots-signal-channel" to="DOTS-SIG-CHANNEL"/>
<?rfc include="reference.RFC.2119"?> <references>
<name>References</name>
<?rfc include="reference.RFC.7252"?> <references>
<name>Normative References</name>
<?rfc include='reference.RFC.8174'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<?rfc include='reference.RFC.7230'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7252.xml"/>
<?rfc include='reference.RFC.8075'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</references> FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7230.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8075.xml"/>
</references>
<references>
<name>Informative References</name>
<references title="Informative References"> <reference anchor="I-D.ietf-dots-signal-channel">
<?rfc include="reference.I-D.ietf-dots-signal-channel"?> <front>
<title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Cha
nnel Specification</title>
<author initials="T" surname="Reddy" fullname="Tirumaleswar Reddy">
<organization/>
</author>
<author initials="M" surname="Boucadair" fullname="Mohamed Boucadair">
<organization/>
</author>
<author initials="P" surname="Patil" fullname="Prashanth Patil">
<organization/>
</author>
<author initials="A" surname="Mortensen" fullname="Andrew Mortensen">
<organization/>
</author>
<author initials="N" surname="Teague" fullname="Nik Teague">
<organization/>
</author>
<date month="January" day="6" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dots-signal-channel-41"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-do
ts-signal-channel-41.txt"/>
</reference>
<?rfc include='reference.RFC.8586'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8586.xml"/>
</references>
</references> </references>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>This specification was part of <xref target="I-D.ietf-dots-signal-chann
el" format="default"/>.
Many thanks to those who reviewed DOTS specifications.</t>
<t>Thanks to <contact fullname="Klaus Hartke"/>, <contact fullname="Carste
n Bormann"/>,
<contact fullname="Peter van der Stok"/>, <contact fullname="Jim Schaad"/>
,
<contact fullname="Jaime Jiménez"/>, <contact fullname="Roni Even"/>,
<contact fullname="Scott Bradner"/>, <contact fullname="Thomas Fossati"/>,
<contact fullname="Radia Perlman"/>, <contact fullname="Éric Vyncke"/>,
<contact fullname="Suresh Krishnan"/>, <contact fullname="Roman Danyliw"/>
,
<contact fullname="Barry Leiba"/>, <contact fullname="Christer Holmberg"/>
,
<contact fullname="Benjamin Kaduk"/>, and <contact fullname="Adam Roach"/>
for their
review and comments.</t>
<t><contact fullname="Carsten Bormann"/> provided the "Intended Usage" tex
t.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 92 change blocks. 
249 lines changed or deleted 286 lines changed or added

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