rfc9715xml2.original.xml   rfc9715.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.
2.4) -->
<!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;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-dnsop-avoid-fragmentation-20" categor <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
y="info" consensus="true" submissionType="IETF" tocDepth="4" tocInclude="true" s -ietf-dnsop-avoid-fragmentation-20" number="9715" category="info" consensus="tru
ortRefs="true" symRefs="true"> e" submissionType="IETF" tocDepth="4" tocInclude="true" sortRefs="true" symRefs=
<front> "true" obsoletes="" updates="" version="3" xml:lang="en">
<title abbrev="avoid-fragmentation">IP Fragmentation Avoidance in DNS over U
DP</title>
<front>
<title abbrev="Avoid IP Fragmentation">IP Fragmentation Avoidance in DNS ove
r UDP</title>
<seriesInfo name="RFC" value="9715"/>
<author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara"> <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara">
<organization abbrev="JPRS">Japan Registry Services Co., Ltd.</organizatio n> <organization abbrev="JPRS">Japan Registry Services Co., Ltd.</organizatio n>
<address> <address>
<postal> <postal>
<street>Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda</street> <street>Chiyoda First Bldg. East 13F</street>
<region>Chiyoda-ku, Tokyo</region> <street>3-8-1 Nishi-Kanda</street>
<region>Chiyoda-ku, Tokyo</region>
<code>101-0065</code> <code>101-0065</code>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<phone>+81 3 5215 8451</phone> <phone>+81 3 5215 8451</phone>
<email>fujiwara@jprs.co.jp</email> <email>fujiwara@jprs.co.jp</email>
</address> </address>
</author> </author>
<author initials="P." surname="Vixie" fullname="Paul Vixie"> <author initials="P." surname="Vixie" fullname="Paul Vixie">
<organization>AWS Security</organization> <organization>AWS Security</organization>
<address> <address>
<postal> <postal>
<street>11400 La Honda Road</street> <street>11400 La Honda Road</street>
<city>Woodside, CA</city> <city>Woodside</city>
<region>CA</region>
<code>94062</code> <code>94062</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 650 393 3994</phone> <phone>+1 650 393 3994</phone>
<email>paul@redbarn.org</email> <email>paul@redbarn.org</email>
</address> </address>
</author> </author>
<date year="2025" month="January"/>
<date year="2024" month="September" day="26"/> <area>OPS</area>
<workgroup>dnsop</workgroup>
<area>operations</area>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<?line 129?>
<t>The widely <t>The widely
deployed EDNS0 feature in the DNS enables a DNS receiver to indicate deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a DNS receiver to indicate
its received UDP message size capacity, which supports the sending of its received UDP message size capacity, which supports the sending of
large UDP responses by a DNS server. large UDP responses by a DNS server.
Large DNS/UDP messages are more likely to be fragmented Large DNS/UDP messages are more likely to be fragmented,
and IP fragmentation has exposed weaknesses in application protocols. and IP fragmentation has exposed weaknesses in application protocols.
It is possible to avoid IP fragmentation in DNS by limiting the response It is possible to avoid IP fragmentation in DNS by limiting the response
size where possible, and signaling the need to upgrade from UDP to TCP size where possible and signaling the need to upgrade from UDP to TCP
transport where necessary. transport where necessary.
This document describes techniques to avoid IP fragmentation in DNS.</t> This document describes techniques to avoid IP fragmentation in DNS.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 142?>
<?line 142?> <section anchor="introduction">
<name>Introduction</name>
<section anchor="introduction"><name>Introduction</name> <t>This document was originally intended to be a Best Current Practice, bu
t due to
<t>This document was originally intended to be a BCP, but due to
operating system and socket option limitations, some of the operating system and socket option limitations, some of the
recommendations have not yet gained real-world experience and recommendations have not yet gained real-world experience;
therefore the document is published as Informational. therefore, this document is Informational.
It is hoped and expected that, as operating systems and implementations evolve, It is expected that, as operating systems and implementations evolve,
we will gain more experience with the recommendations, and plan to publish an we will gain more experience with the recommendations and will publish an
updated document as a Best Current Practice.</t> updated document as a Best Current Practice in the future.</t>
<t>DNS has an EDNS(0) mechanism <xref target="RFC6891"/>.
<t>DNS has an EDNS0 <xref target="RFC6891"/> mechanism. The widely deployed EDNS(0) feature in the DNS enables a DNS receiver to indicat
The widely e
deployed EDNS0 feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of
its received UDP message size capacity which supports the sending of
large UDP responses by a DNS server. large UDP responses by a DNS server.
DNS over UDP invites IP fragmentation when a packet is larger than the DNS over UDP invites IP fragmentation when a packet is larger than the
MTU of some network in the packet's path.</t> Maximum Transmission Unit (MTU) of some network in the packet's path.</t>
<t>Fragmented DNS UDP responses have systemic weaknesses, which expose
<t>Fragmented DNS UDP responses have systemic weaknesses, which expose the requestor to DNS cache poisoning from off-path attackers (see <xref target="
the requestor to DNS cache poisoning from off-path attackers. ProblemOfFragmentation"/> for references and details).</t>
(See <xref target="ProblemOfFragmentation"/> for references and details.)</t> <t><xref target="RFC8900"/> states that IP fragmentation
<t><xref target="RFC8900"/> states that IP fragmentation
introduces fragility to Internet communication. introduces fragility to Internet communication.
The transport of DNS messages The transport of DNS messages
over UDP should take account of the observations stated in that document.</t> over UDP should take account of the observations stated in that document.</t>
<t>TCP avoids fragmentation by segmenting data into packets that are small
<t>TCP avoids fragmentation by segmenting data into packets that are smaller er
than or equal to the Maximum Segment Size (MSS). than or equal to the Maximum Segment Size (MSS). For each transmitted segm
For each transmitted segment, the size of the IP and TCP headers is known, ent, the size of the IP and TCP headers is known,
and the IP packet size can be chosen to keep it within the estimated MTU and the and the IP packet size can be chosen to keep it within the estimated MTU and the
other end's MSS. MSS. This takes advantage of the elasticity of the TCP's
This takes advantage of the elasticity of TCP's packetizing process, depending on how much queued data will fit into the next
packetizing process as to how much queued data will fit into the next
segment. In contrast, DNS over UDP has little datagram size elasticity and segment. In contrast, DNS over UDP has little datagram size elasticity and
lacks insight into IP header and option size, so we must make more lacks insight into IP header and option size, so we must make more
conservative estimates about available UDP payload space.</t> conservative estimates about available UDP payload space.</t>
<t><xref target="RFC7766"/> states that all general-purpose DNS
implementations <bcp14>MUST</bcp14> support both UDP and TCP transport.</t
>
<t><xref target="RFC7766"/> states that all general-purpose DNS <t>DNS transaction security <xref target="RFC8945"/> <xref target="RFC2931
implementations MUST support both UDP and TCP transport.</t> "/> does protect
against the security risks of fragmentation, and it protects
<t>DNS transaction security <xref target="RFC8945"/> <xref target="RFC2931"/> do
es protect
against the security risks of fragmentation, including protecting
delegation responses. But <xref target="RFC8945"/> has limited applicability due delegation responses. But <xref target="RFC8945"/> has limited applicability due
to key distribution requirements and there is little if any deployment to key distribution requirements, and there is little if any deployment
of <xref target="RFC2931"/>.</t> of <xref target="RFC2931"/>.</t>
<t>This document describes various techniques to avoid IP fragmentation
<t>This document describes various techniques to avoid IP fragmentation
of UDP packets in DNS. of UDP packets in DNS.
This document is primarily applicable to DNS use on the global Internet.</t> This document is primarily applicable to DNS use on the global Internet.</t>
<t>In contrast, a path MTU that deviates from the
<t>In contrast, a path MTU that deviates from the
recommended value might be obtained through static configuration, server recommended value might be obtained through static configuration, server
routing hints, or a future discovery protocol. However, addressing routing hints, or a future discovery protocol. However, addressing
this falls outside the scope of this document and may be the subject this falls outside the scope of this document and may be the subject
of future specifications.</t> of future specifications.</t>
</section>
<section anchor="terminology">
<name>Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
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>
</section> <t>The definitions of "requestor" and "responder" are per <xref target="RFC6891"
<section anchor="terminology"><name>Terminology</name> />:</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the
y appear in all
capitals, as shown here.</t>
<t>"Requestor" refers to the side that sends a request. "Responder"
refers to an authoritative server, recursive resolver or other DNS component
that responds to questions. (Quoted from EDNS0 <xref target="RFC6891"/>)</t>
<t>"Path MTU" is the minimum link MTU of all the links in a path
between a source node and a destination node. (Quoted from <xref target="RFC8201
"/>)</t>
<t>In this document, the term "Path MTU discovery" includes
both Classical Path MTU discovery <xref target="RFC1191"/>, <xref target="RFC820
1"/>, and
Packetization Layer Path MTU discovery <xref target="RFC8899"/>.</t>
<t>Many of the specialized terms used in this document are defined in <blockquote>
DNS Terminology <xref target="RFC8499"/>.</t> "Requestor" refers to the side that sends a request. "Responder"
refers to an authoritative, recursive resolver or other DNS component
that responds to questions.</blockquote>
</section> <t>The definition of "path MTU" is per <xref target="RFC8201"/>:</t>
<section anchor="recommendation"><name>How to avoid IP fragmentation in DNS</nam <blockquote>path MTU [is] the minimum link MTU of all the links in a path
e> between a source node and a destination node.</blockquote>
<t>These recommendations are intended <t>In this document, the term "Path MTU Discovery" includes
both Classical Path MTU Discovery <xref target="RFC1191"/> <xref target="RFC8201
"/> and
Packetization Layer Path MTU Discovery <xref target="RFC8899"/>.</t>
<t>Many of the specialized terms used in this document are defined in
"DNS Terminology" <xref target="RFC9499"/>.</t>
</section>
<section anchor="recommendation">
<name>How to Avoid IP Fragmentation in DNS</name>
<t>These recommendations are intended
for nodes with global IP addresses on the Internet. for nodes with global IP addresses on the Internet.
Private networks or local networks are out of the scope of this document.</t> Private networks or local networks are out of the scope of this document.</t>
<t>The methods to avoid IP fragmentation in DNS are described below:</t>
<section anchor="RecommendationsResponders">
<name>Proposed Recommendations for UDP Responders</name>
<dl spacing="normal" newline="false" indent="7">
<dt>R1.</dt><dd>UDP responders should not use IPv6 fragmentation
<xref target="RFC8200"/>.</dd>
<dt>R2.</dt><dd><t>UDP responders should configure their systems to
prevent fragmentation of UDP packets when sending replies, provided
it can be done safely. The mechanisms to achieve this vary across
different operating systems.</t>
<t>The methods to avoid IP fragmentation in DNS are described below:</t> <t>For BSD-like operating systems, the IP Don't Fragment (DF) flag
bit <xref target="RFC0791"/> can be used to prevent
<section anchor="RecommendationsResponders"><name>Proposed Recommendations for U fragmentation. In contrast, Linux systems do not expose a direct API
DP responders</name> for this purpose and require the use of Path MTU socket options
(IP_MTU_DISCOVER) to manage fragmentation settings. However, it is
<t>R1. UDP responders should not use IPv6 fragmentation <xref target="RFC8200"/> important to note that enabling IPv4 Path MTU Discovery for UDP in
.</t> current Linux versions is considered harmful and dangerous. For more
details, see <xref target="impl"/>.</t></dd>
<t>R2. UDP responders should configure their systems to prevent <dt>R3.</dt><dd>UDP responders should compose response packets that
fragmentation of UDP packets when sending replies, provided it can be fit in the minimum of the offered requestor's maximum UDP payload
done safely. The mechanisms to achieve this vary across different size <xref target="RFC6891"/>, the interface MTU, the network MTU
operating systems.</t> value configured by the knowledge of the network operators, and the
<bcp14>RECOMMENDED</bcp14> maximum DNS/UDP payload size 1400. For more
<t>For BSD-like operating systems, the IP "Don't Fragment flag (DF) bit" details, see
<xref target="RFC0791"></xref> can be used to prevent fragmentation. In contra <xref target="details"/>.</dd>
st, Linux <dt>R4.</dt><dd>If the UDP responder detects an immediate error
systems do not expose a direct API for this purpose and require the indicating that the UDP packet exceeds the path MTU size, the UDP
use of Path MTU socket options (IP_MTU_DISCOVER) to manage responder may recreate response packets that fit in the path MTU
fragmentation settings. However, it is important to note that enabling size or with the TC bit set.</dd>
IPv4 Path MTU Discovery for UDP in current Linux versions is </dl>
considered harmful and dangerous. For more details, refer to <xref target="imp <t>The cause and effect of the TC bit are unchanged <xref target="RFC103
l"/>.</t> 5"/>.</t>
</section>
<t>R3. UDP responders should compose response packets that fit in the minimum of <section anchor="RecommendationsRequestors">
the offered requestor's maximum UDP payload size <xref target="RFC6891"/>, <name>Proposed Recommendations for UDP Requestors</name>
the interface MTU, <dl spacing="normal" newline="false" indent="7">
the network MTU value configured by the knowledge of the network operators, <dt>R5.</dt><dd>UDP requestors should limit the requestor's maximum
and the RECOMMENDED maximum DNS/UDP payload size 1400. UDP payload size to fit in the minimum of the interface MTU, the
(See <xref target="details"/> for more information.)</t> network MTU value configured by the network operators, and the
<bcp14>RECOMMENDED</bcp14> maximum DNS/UDP payload size 1400. A
<t>R4. If the UDP responder detects an immediate error indicating smaller limit may be allowed. For more details, see <xref target="deta
that the UDP packet exceeds the path MTU size, ils"/>.</dd>
the UDP responder may recreate response packets that fit in the path MTU size,
or with the TC bit set.</t>
<t>The cause and effect of the TC bit are unchanged <xref target="RFC1035"/>.</t
>
</section>
<section anchor="RecommendationsRequestors"><name>Proposed Recommendations for U
DP requestors</name>
<t>R5. UDP requestors should limit the requestor's maximum UDP payload size
to fit in the minimum of
the interface MTU,
the network MTU value configured by the network operators,
and the RECOMMENDED maximum DNS/UDP payload size 1400.
A smaller limit may be allowed.
(See <xref target="details"/> for more information.)</t>
<t>R6. UDP requestors should/may drop fragmented DNS/UDP responses without IP re
assembly
to avoid cache poisoning attacks (at firewall function).</t>
<t>R7. DNS responses may be dropped by IP fragmentation.
Requestors are
recommended to try alternative transport protocols eventually.</t>
</section>
</section>
<section anchor="RecommendationOperators"><name>Proposed Recommendations for DNS
operators</name>
<t>Large DNS responses are typically the result of zone configuration.
People who publish information in the DNS should seek configurations resulting i
n small responses.
For example,</t>
<t>R8. Use a smaller number of name servers.</t>
<t>R9. Use a smaller number of A/AAAA RRs for a domain name.</t>
<t>R10. Use minimal-responses configuration:
Some implementations have a 'minimal responses' configuration option that caus
es
DNS servers to make response packets smaller, containing only mandatory
and required data (<xref target="minimal-responses"/>).</t>
<t>R11. Use a smaller signature / public key size algorithm for DNSSEC.
Notably, the signature sizes of ECDSA and EdDSA
are smaller than those of equivalent cryptographic strength using RSA.</t>
<t>It is difficult to determine a specific upper limit for R8, R9, and <dt>R6.</dt><dd>UDP requestors should drop fragmented DNS/UDP
responses without IP reassembly to avoid cache poisoning attacks (at
the firewall function).</dd>
<dt>R7.</dt><dd>DNS responses may be dropped by IP fragmentation.
It is recommended that requestors eventually try alternative transport
protocols.</dd>
</dl>
</section>
</section>
<section anchor="RecommendationOperators">
<name>Proposed Recommendations for DNS Operators</name>
<t>Large DNS responses are typically the result of zone configuration.
People who publish information in the DNS should seek configurations
resulting in small responses. For example:</t>
<dl spacing="normal" newline="false" indent="7">
<dt>R8.</dt><dd>Use a smaller number of name servers.</dd>
<dt>R9.</dt><dd>Use a smaller number of A/AAAA RRs for a domain name.</dd
>
<dt>R10.</dt><dd>Use minimal-responses configuration: Some
implementations have a 'minimal responses' configuration option that
causes DNS servers to make response packets smaller by containing only
mandatory and required data (<xref target="minimal-responses"/>).</dd>
<dt>R11.</dt><dd>Use a smaller signature / public key size algorithm
for DNSSEC. Notably, the signature sizes of the Elliptic Curve Digital S
ignature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA
) are
smaller than those of equivalent cryptographic strength using RSA.</dd>
</dl>
<t>It is difficult to determine a specific upper limit for R8, R9, and
R11, but it is sufficient if all responses from the DNS servers are R11, but it is sufficient if all responses from the DNS servers are
below the size of R3 and R5.</t> below the size of R3 and R5.</t>
</section>
</section> <section anchor="protocol">
<section anchor="protocol"><name>Protocol compliance considerations</name> <name>Protocol Compliance Considerations</name>
<t>Some authoritative servers deviate from the DNS standard as follows:</t
<t>Some authoritative servers deviate from the DNS standard as follows:</t> >
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Some authoritative servers ignore the EDNS0 requestor's maximum UDP payload <t>Some authoritative servers ignore the EDNS(0) requestor's maximum U
size and return large UDP responses. <xref target="Fujiwara2018"></xref></t> DP payload size and return large UDP responses <xref target="Fujiwara2018"/>.</t
<t>Some authoritative servers do not support TCP transport.</t> >
</list></t> </li>
<li>
<t>Such non-compliant behavior cannot become implementation or configuration <t>Some authoritative servers do not support TCP transport.</t>
</li>
</ul>
<t>Such non-compliant behavior cannot become implementation or configurati
on
constraints for the rest of the DNS. If failure is the result, then that constraints for the rest of the DNS. If failure is the result, then that
failure must be localized to the non-compliant servers.</t> failure must be localized to the non-compliant servers.</t>
</section>
</section> <section anchor="iana">
<section anchor="iana"><name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document requests no IANA actions.</t> <t>This document has no IANA actions.</t>
</section>
</section> <section anchor="securitycons">
<section anchor="securitycons"><name>Security Considerations</name> <name>Security Considerations</name>
<section anchor="on-path-fragmentation-on-ipv4">
<section anchor="on-path-fragmentation-on-ipv4"><name>On-path fragmentation on I <name>On-Path Fragmentation on IPv4</name>
Pv4</name> <t>If the Don't Fragment (DF) flag bit is not set,
<t>If the Don't Fragment (DF) bit is not set,
on-path fragmentation may happen on IPv4, on-path fragmentation may happen on IPv4,
and lead to vulnerabilities, as shown in <xref target="ProblemOfFragmentation"/> and it can lead to vulnerabilities as shown in <xref target="ProblemOfFragmentat
. ion"/>.
To avoid this, recommendation R6 needs to be used To avoid this, R6 needs to be used to discard the fragmented responses and retry
to discard the fragmented responses and retry by TCP.</t> using TCP.</t>
</section>
</section> <section anchor="small-mtu-network">
<section anchor="small-mtu-network"><name>Small MTU network</name> <name>Small MTU Network</name>
<t>When avoiding fragmentation,
<t>When avoiding fragmentation,
a DNS/UDP requestor behind a small MTU network may experience a DNS/UDP requestor behind a small MTU network may experience
UDP timeouts, which would reduce performance UDP timeouts, which would reduce performance
and which may lead to TCP fallback. and may lead to TCP fallback.
This would indicate prior reliance upon IP fragmentation, This would indicate prior reliance upon IP fragmentation,
which is considered to be harmful which is considered to be harmful
to both the performance and stability of applications, endpoints, and gateways. to both the performance and stability of applications, endpoints, and gateways.
Avoiding IP fragmentation will improve operating conditions overall, Avoiding IP fragmentation will improve operating conditions overall,
and the performance of DNS/TCP has increased and will continue to increase.</t> and the performance of DNS/TCP has increased and will continue to increase.</t>
<t>If a UDP response packet is dropped in transit,
<t>If a UDP response packet is dropped in transit,
up to and including the network stack of the initiator, up to and including the network stack of the initiator,
it increases the attack window for poisoning the requestor's cache.</t> it increases the attack window for poisoning the requestor's cache.</t>
</section>
</section> <section anchor="ProblemOfFragmentation">
<section anchor="ProblemOfFragmentation"><name>Weaknesses of IP fragmentation</n <name>Weaknesses of IP Fragmentation</name>
ame> <t>"Fragmentation Considered Poisonous" <xref target="Herzberg2013"/> no
tes effective
<t>"Fragmentation Considered Poisonous" <xref target="Herzberg2013"></xref> note
d effective
off-path DNS cache poisoning attack vectors using IP fragmentation. off-path DNS cache poisoning attack vectors using IP fragmentation.
"IP fragmentation attack on DNS" <xref target="Hlavacek2013"></xref> and "Domain "IP fragmentation attack on DNS" <xref target="Hlavacek2013"/> and "Domain Valid
Validation++ ation++
For MitM-Resilient PKI" <xref target="Brandt2018"></xref> noted that off-path at For MitM-Resilient PKI" <xref target="Brandt2018"/> note that off-path attackers
tackers can intervene in the Path MTU Discovery <xref target="RFC1191"/>
can intervene in the path MTU discovery <xref target="RFC1191"/>
to cause authoritative servers to produce fragmented responses. to cause authoritative servers to produce fragmented responses.
<xref target="RFC7739"/> stated the <xref target="RFC7739"/> states the
security implications of predictable fragment identification values.</t> security implications of predictable fragment identification values.</t>
<t>In Section 3.2 (Message Side Guidelines) of UDP Usage Guidelines <xref target <t><xref section="3.2" sectionFormat="of" target="RFC8085"/> states that
="RFC8085"/> "an application <bcp14>SHOULD NOT</bcp14> send UDP datagrams
we are told that an application SHOULD NOT send UDP datagrams
that result in IP packets that exceed the Maximum Transmission Unit (MTU) that result in IP packets that exceed the Maximum Transmission Unit (MTU)
along the path to the destination.</t> along the path to the destination".</t>
<t>A DNS message receiver cannot trust fragmented UDP datagrams primaril
<t>A DNS message receiver cannot trust fragmented UDP datagrams primarily due to y due to
the small amount of entropy provided by UDP port numbers and DNS message the small amount of entropy provided by UDP port numbers and DNS message
identifiers, each of which being only 16 bits in size, and both likely identifiers, each of which is only 16 bits in size, and both are likely
being in the first fragment of a packet if fragmentation occurs. to be in the first fragment of a packet if fragmentation occurs.
By comparison, the TCP protocol stack controls packet size and avoids IP fragmen tation under ICMP NEEDFRAG attacks. By comparison, the TCP protocol stack controls packet size and avoids IP fragmen tation under ICMP NEEDFRAG attacks.
In TCP, fragmentation should be avoided for performance reasons, whereas for In TCP, fragmentation should be avoided for performance reasons, whereas for
UDP, fragmentation should be avoided for resiliency and authenticity reasons.</t > UDP, fragmentation should be avoided for resiliency and authenticity reasons.</t >
</section>
</section> <section anchor="dns-security-protections">
<section anchor="dns-security-protections"><name>DNS Security Protections</name> <name>DNS Security Protections</name>
<t>DNSSEC is a countermeasure against cache poisoning attacks that use
<t>DNSSEC is a countermeasure against cache poisoning attacks that use
IP fragmentation. IP fragmentation.
However, DNS delegation responses are not signed with DNSSEC, However, DNS delegation responses are not signed with DNSSEC,
and DNSSEC does not have a mechanism to get the correct response if and DNSSEC does not have a mechanism to get the correct response if
an incorrect delegation is injected. This is a denial-of-service an incorrect delegation is injected. This is a denial-of-service
vulnerability that can yield failed name resolutions. vulnerability that can yield failed name resolutions.
If cache poisoning attacks can be avoided, If cache poisoning attacks can be avoided,
DNSSEC validation failures will be avoided.</t> DNSSEC validation failures will be avoided.</t>
</section>
</section> <section anchor="possible-actions-for-resolver-operators">
<section anchor="possible-actions-for-resolver-operators"><name>Possible actions <name>Possible Actions for Resolver Operators</name>
for resolver operators</name> <t>Because this document is published as Informational
rather than a Best Current Practice,
<t>Because this document is published as an "Informational" document
rather than a "Best Current Practice,"
this section presents steps that resolver operators can take this section presents steps that resolver operators can take
to avoid vulnerabilities related to IP fragmentation.</t> to avoid vulnerabilities related to IP fragmentation.</t>
<t>To avoid vulnerabilities related to IP fragmentation,
implement R5 and R6.</t>
<t>To avoid vulnerabilities related to IP fragmentation, <t>Specifically, configure the firewall functions protecting the full-se
implement R5 and R6.</t> rvice resolver
<t>Specifically, configure the firewall functions protecting the full-service re
solver
to discard incoming DNS response packets to discard incoming DNS response packets
with a non-zero Fragment offset or a More Fragments (MF) bit of 1 on IPv4, with a non-zero Fragment Offset (FO) or a More Fragments (MF) flag bit of 1 on I Pv4,
and discard packets with IPv6 Fragment Headers. and discard packets with IPv6 Fragment Headers.
(If the resolver's IP address is not dedicated to the DNS resolver (If the resolver's IP address is not dedicated to the DNS resolver
and uses UDP communication that relies on IP Fragmentation for purposes and uses UDP communication that relies on IP Fragmentation for purposes
other than DNS, discard only the first fragment that contains the UDP header other than DNS, discard only the first fragment that contains the UDP header
from port 53.)</t> from port 53.)</t>
<t>The most recent resolver software is believed to implement R7.</t>
<t>The most recent resolver software is believed to implement R7.</t> <t>Even if R7 is not implemented, it will only result in a name resoluti
on error,
<t>Even if R7 is not implemented, it will only result in a name resolution error
,
preventing attacks from leading to malicious sites.</t> preventing attacks from leading to malicious sites.</t>
</section>
</section> </section>
</section>
<section anchor="acknowledgments"><name>Acknowledgments</name>
<t>The author would like to specifically thank
Paul Wouters,
Mukund Sivaraman,
Tony Finch,
Hugo Salgado,
Peter van Dijk,
Brian Dickson,
Puneet Sood,
Jim Reid,
Petr Spacek,
Andrew McConachie,
Joe Abley,
Daisuke Higashi,
Joe Touch,
Wouter Wijngaards,
Vladimir Cunat,
Benno Overeinder
and
Štěpán Němec
for extensive review and comments.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references anchor="sec-normative-references">
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
891.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
766.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
945.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
931.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
201.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
191.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
899.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
499.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
200.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
035.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
739.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
085.xml"/>
</references>
<references anchor="sec-informative-references">
<name>Informative References</name>
<references title='Normative References' anchor="sec-normative-references"> <reference anchor="Brandt2018" target="https://dl.acm.org/doi/10.1145/32
43734.3243790">
<reference anchor="RFC6891"> <front>
<front> <title>Domain Validation++ For MitM-Resilient PKI</title>
<title>Extension Mechanisms for DNS (EDNS(0))</title> <author initials="M." surname="Brandt" fullname="Markus Brandt">
<author fullname="J. Damas" initials="J." surname="Damas"/> <organization>Fraunhofer Institute for Secure Information Technolo
<author fullname="M. Graff" initials="M." surname="Graff"/> gy SIT, Darmstadt, Germany</organization>
<author fullname="P. Vixie" initials="P." surname="Vixie"/> </author>
<date month="April" year="2013"/> <author initials="T." surname="Dai" fullname="Tianxiang Dai">
<abstract> <organization>Fraunhofer Institute for Secure Information Technolo
<t>The Domain Name System's wire protocol includes a number of fixed field gy SIT, Darmstadt, Germany</organization>
s whose range has been or soon will be exhausted and does not allow requestors t </author>
o advertise their capabilities to responders. This document describes backward-c <author initials="A." surname="Klein" fullname="Amit Klein">
ompatible mechanisms for allowing the protocol to grow.</t> <organization>Fraunhofer Institute for Secure Information Technolo
<t>This document updates the Extension Mechanisms for DNS (EDNS(0)) specif gy SIT, Darmstadt, Germany</organization>
ication (and obsoletes RFC 2671) based on feedback from deployment experience in </author>
several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Doma <author initials="H." surname="Shulman" fullname="Haya Shulman">
in Name System") and adds considerations on the use of extended labels in the DN <organization>Fraunhofer Institute for Secure Information Technolo
S.</t> gy SIT, Darmstadt, Germany</organization>
</abstract> </author>
</front> <author initials="M." surname="Waidner" fullname="Michael Waidner">
<seriesInfo name="STD" value="75"/> <organization>Fraunhofer Institute for Secure Information Technolo
<seriesInfo name="RFC" value="6891"/> gy SIT, Darmstadt, Germany</organization>
<seriesInfo name="DOI" value="10.17487/RFC6891"/> </author>
</reference> <date month="October" year="2018"/>
</front>
<reference anchor="RFC7766"> <refcontent>Proceedings of the 2018 ACM SIGSAC Conference on Computer
<front> and Communications Security, pp. 2060-2076</refcontent>
<title>DNS Transport over TCP - Implementation Requirements</title> <seriesInfo name="DOI" value="10.1145/3243734.3243790"/>
<author fullname="J. Dickinson" initials="J." surname="Dickinson"/> </reference>
<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
<author fullname="R. Bellis" initials="R." surname="Bellis"/>
<author fullname="A. Mankin" initials="A." surname="Mankin"/>
<author fullname="D. Wessels" initials="D." surname="Wessels"/>
<date month="March" year="2016"/>
<abstract>
<t>This document specifies the requirement for support of TCP as a transpo
rt protocol for DNS implementations and provides guidelines towards DNS-over-TCP
performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966
and therefore updates RFC 1035 and RFC 1123.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7766"/>
<seriesInfo name="DOI" value="10.17487/RFC7766"/>
</reference>
<reference anchor="RFC8945">
<front>
<title>Secret Key Transaction Authentication for DNS (TSIG)</title>
<author fullname="F. Dupont" initials="F." surname="Dupont"/>
<author fullname="S. Morris" initials="S." surname="Morris"/>
<author fullname="P. Vixie" initials="P." surname="Vixie"/>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
<author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson"/>
<author fullname="B. Wellington" initials="B." surname="Wellington"/>
<date month="November" year="2020"/>
<abstract>
<t>This document describes a protocol for transaction-level authentication
using shared secrets and one-way hashing. It can be used to authenticate dynami
c updates to a DNS zone as coming from an approved client or to authenticate res
ponses as coming from an approved name server.</t>
<t>No recommendation is made here for distributing the shared secrets; it
is expected that a network administrator will statically configure name servers
and clients using some out-of-band mechanism.</t>
<t>This document obsoletes RFCs 2845 and 4635.</t>
</abstract>
</front>
<seriesInfo name="STD" value="93"/>
<seriesInfo name="RFC" value="8945"/>
<seriesInfo name="DOI" value="10.17487/RFC8945"/>
</reference>
<reference anchor="RFC2931">
<front>
<title>DNS Request and Transaction Signatures ( SIG(0)s )</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
<date month="September" year="2000"/>
<abstract>
<t>This document describes the minor but non-interoperable changes in Requ
est and Transaction signature resource records ( SIG(0)s ) that implementation e
xperience has deemed necessary. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2931"/>
<seriesInfo name="DOI" value="10.17487/RFC2931"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the
requirements in the specification. These words are often capitalized. This docu
ment defines these words as they should be interpreted in IETF documents. This d
ocument specifies an Internet Best Current Practices for the Internet Community,
and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specif
ications. This document aims to reduce the ambiguity by clarifying that only UPP
ERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8201">
<front>
<title>Path MTU Discovery for IP version 6</title>
<author fullname="J. McCann" initials="J." surname="McCann"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="J. Mogul" initials="J." surname="Mogul"/>
<author fullname="R. Hinden" initials="R." role="editor" surname="Hinden"/>
<date month="July" year="2017"/>
<abstract>
<t>This document describes Path MTU Discovery (PMTUD) for IP version 6. It
is largely derived from RFC 1191, which describes Path MTU Discovery for IP ver
sion 4. It obsoletes RFC 1981.</t>
</abstract>
</front>
<seriesInfo name="STD" value="87"/>
<seriesInfo name="RFC" value="8201"/>
<seriesInfo name="DOI" value="10.17487/RFC8201"/>
</reference>
<reference anchor="RFC1191">
<front>
<title>Path MTU discovery</title>
<author fullname="J. Mogul" initials="J." surname="Mogul"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<date month="November" year="1990"/>
<abstract>
<t>This memo describes a technique for dynamically discovering the maximum
transmission unit (MTU) of an arbitrary internet path. It specifies a small cha
nge to the way routers generate one type of ICMP message. For a path that passes
through a router that has not been so changed, this technique might not discove
r the correct Path MTU, but it will always choose a Path MTU as accurate as, and
in many cases more accurate than, the Path MTU that would be chosen by current
practice. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1191"/>
<seriesInfo name="DOI" value="10.17487/RFC1191"/>
</reference>
<reference anchor="RFC8899">
<front>
<title>Packetization Layer Path MTU Discovery for Datagram Transports</title
>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="T. Jones" initials="T." surname="Jones"/>
<author fullname="M. Tüxen" initials="M." surname="Tüxen"/>
<author fullname="I. Rüngeler" initials="I." surname="Rüngeler"/>
<author fullname="T. Völker" initials="T." surname="Völker"/>
<date month="September" year="2020"/>
<abstract>
<t>This document specifies Datagram Packetization Layer Path MTU Discovery
(DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram
Packetization Layers (PLs). It allows a PL, or a datagram application that uses
a PL, to discover whether a network path can support the current size of datagr
am. This can be used to detect and reduce the message size when a sender encount
ers a packet black hole. It can also probe a network path to discover whether th
e maximum packet size can be increased. This provides functionality for datagram
transports that is equivalent to the PLPMTUD specification for TCP, specified i
n RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer
to this method for use with UDP datagrams and updates SCTP.</t>
<t>The document provides implementation notes for incorporating Datagram P
MTUD into IETF datagram transports or applications that use datagram transports.
</t>
<t>This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and
RFC 8261.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8899"/>
<seriesInfo name="DOI" value="10.17487/RFC8899"/>
</reference>
<reference anchor="RFC8499">
<front>
<title>DNS Terminology</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
<date month="January" year="2019"/>
<abstract>
<t>The Domain Name System (DNS) is defined in literally dozens of differen
t RFCs. The terminology used by implementers and developers of DNS protocols, an
d by operators of DNS systems, has sometimes changed in the decades since the DN
S was first defined. This document gives current definitions for many of the ter
ms used in the DNS in a single document.</t>
<t>This document obsoletes RFC 7719 and updates RFC 2308.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8499"/>
<seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>
<reference anchor="RFC8200">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<date month="July" year="2017"/>
<abstract>
<t>This document specifies version 6 of the Internet Protocol (IPv6). It o
bsoletes RFC 2460.</t>
</abstract>
</front>
<seriesInfo name="STD" value="86"/>
<seriesInfo name="RFC" value="8200"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
<reference anchor="RFC1035">
<front>
<title>Domain names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised specification of the protocol and format used i
n the implementation of the Domain Name System. It obsoletes RFC-883. This memo
documents the details of the domain name client - server communication.</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<seriesInfo name="DOI" value="10.17487/RFC1035"/>
</reference>
<reference anchor="RFC7739">
<front>
<title>Security Implications of Predictable Fragment Identification Values</
title>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<date month="February" year="2016"/>
<abstract>
<t>IPv6 specifies the Fragment Header, which is employed for the fragmenta
tion and reassembly mechanisms. The Fragment Header contains an "Identification"
field that, together with the IPv6 Source Address and the IPv6 Destination Addr
ess of a packet, identifies fragments that correspond to the same original datag
ram, such that they can be reassembled together by the receiving host. The only
requirement for setting the Identification field is that the corresponding value
must be different than that employed for any other fragmented datagram sent rec
ently with the same Source Address and Destination Address. Some implementations
use a simple global counter for setting the Identification field, thus leading
to predictable Identification values. This document analyzes the security implic
ations of predictable Identification values, and provides implementation guidanc
e for setting the Identification field of the Fragment Header, such that the afo
rementioned security implications are mitigated.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7739"/>
<seriesInfo name="DOI" value="10.17487/RFC7739"/>
</reference>
<reference anchor="RFC8085">
<front>
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="G. Shepherd" initials="G." surname="Shepherd"/>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-passing tra
nsport that has no inherent congestion control mechanisms. This document provide
s guidelines on the use of UDP for the designers of applications, tunnels, and o
ther protocols that use UDP. Congestion control guidelines are a primary focus,
but the document also provides guidance on other topics, including message sizes
, reliability, checksums, middlebox traversal, the use of Explicit Congestion No
tification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
<t>Because congestion control is critical to the stable operation of the I
nternet, applications and other protocols that choose to use UDP as an Internet
transport must employ mechanisms to prevent congestion collapse and to establish
some degree of fairness with concurrent traffic. They may also need to implemen
t additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protocols (e.g.
, protocols layered directly on IP or via IP-based tunnels), especially when the
se protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multicast UDP
usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
</references>
<references title='Informative References' anchor="sec-informative-reference
s">
<reference anchor="Brandt2018" >
<front>
<title>Domain Validation++ For MitM-Resilient PKI</title>
<author initials="M." surname="Brandt" fullname="Markus Brandt">
<organization>Fraunhofer Institute for Secure Information Technology SIT,
Darmstadt, Germany</organization>
</author>
<author initials="T." surname="Dai" fullname="Tianxiang Dai">
<organization>Fraunhofer Institute for Secure Information Technology SIT,
Darmstadt, Germany</organization>
</author>
<author initials="A." surname="Klein" fullname="Amit Klein">
<organization>Fraunhofer Institute for Secure Information Technology SIT,
Darmstadt, Germany</organization>
</author>
<author initials="H." surname="Shulman" fullname="Haya Shulman">
<organization>Fraunhofer Institute for Secure Information Technology SIT,
Darmstadt, Germany</organization>
</author>
<author initials="M." surname="Waidner" fullname="Michael Waidner">
<organization>Fraunhofer Institute for Secure Information Technology SIT,
Darmstadt, Germany</organization>
</author>
<date year="2018"/>
</front>
<seriesInfo name="Proceedings of the 2018 ACM SIGSAC Conference on Computer an
d Communications Security" value=""/>
</reference>
<reference anchor="Herzberg2013" >
<front>
<title>Fragmentation Considered Poisonous</title>
<author initials="A." surname="Herzberg" fullname="Amir Herzberg">
<organization></organization>
</author>
<author initials="H." surname="Shulman" fullname="Haya Shulman">
<organization></organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IEEE Conference on Communications and Network Security" valu
e=""/>
</reference>
<reference anchor="Hlavacek2013" target="https://ripe67.ripe.net/presentations/2
40-ipfragattack.pdf">
<front>
<title>IP fragmentation attack on DNS</title>
<author initials="T." surname="Hlavacek" fullname="Tomas Hlavacek">
<organization>cz.nic</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="RIPE 67 Meeting" value=""/>
</reference>
<reference anchor="Fujiwara2018" >
<front>
<title>Measures against cache poisoning attacks using IP fragmentation in DN
S</title>
<author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara">
<organization>JPRS</organization>
</author>
<date year="2019"/>
</front>
<seriesInfo name="OARC 30 Workshop" value=""/>
</reference>
<reference anchor="DNSFlagDay2020" target="https://dnsflagday.net/2020/">
<front>
<title>DNS flag day 2020</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="Huston2021" >
<front>
<title>Measuring DNS Flag Day 2020</title>
<author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>APNIC Labs</organization>
</author>
<author initials="J." surname="Damas" fullname="Joao Damas">
<organization>APNIC Labs</organization>
</author>
<date year="2021" month="February"/>
</front>
<seriesInfo name="OARC 34 Workshop" value=""/>
</reference>
<reference anchor="RFC8900">
<front>
<title>IP Fragmentation Considered Fragile</title>
<author fullname="R. Bonica" initials="R." surname="Bonica"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="G. Huston" initials="G." surname="Huston"/>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<author fullname="O. Troan" initials="O." surname="Troan"/>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<date month="September" year="2020"/>
<abstract>
<t>This document describes IP fragmentation and explains how it introduces
fragility to Internet communication.</t>
<t>This document also proposes alternatives to IP fragmentation and provid
es recommendations for developers and network operators.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="230"/>
<seriesInfo name="RFC" value="8900"/>
<seriesInfo name="DOI" value="10.17487/RFC8900"/>
</reference>
<reference anchor="RFC0791">
<front>
<title>Internet Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel"/>
<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="RFC4035"> <reference anchor="Herzberg2013" target="https://ieeexplore.ieee.org/doc
<front> ument/6682711">
<title>Protocol Modifications for the DNS Security Extensions</title> <front>
<author fullname="R. Arends" initials="R." surname="Arends"/> <title>Fragmentation Considered Poisonous, or: One-domain-to-rule-th
<author fullname="R. Austein" initials="R." surname="Austein"/> em-all.org</title>
<author fullname="M. Larson" initials="M." surname="Larson"/> <author initials="A." surname="Herzberg" fullname="Amir Herzberg">
<author fullname="D. Massey" initials="D." surname="Massey"/> <organization/>
<author fullname="S. Rose" initials="S." surname="Rose"/> </author>
<date month="March" year="2005"/> <author initials="H." surname="Shulman" fullname="Haya Shulman">
<abstract> <organization/>
<t>This document is part of a family of documents that describe the DNS Se </author>
curity Extensions (DNSSEC). The DNS Security Extensions are a collection of new <date year="2013"/>
resource records and protocol modifications that add data origin authentication </front>
and data integrity to the DNS. This document describes the DNSSEC protocol modif <refcontent>IEEE Conference on Communications and Network Security (CN
ications. This document defines the concept of a signed zone, along with the req S)</refcontent>
uirements for serving and resolving by using DNSSEC. These techniques allow a se <seriesInfo name="DOI" value="10.1109/CNS.2013.6682711"/>
curity-aware resolver to authenticate both DNS resource records and authoritativ </reference>
e DNS error indications.</t>
<t>This document obsoletes RFC 2535 and incorporates changes from all upda
tes to RFC 2535. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4035"/>
<seriesInfo name="DOI" value="10.17487/RFC4035"/>
</reference>
<reference anchor="RFC9471"> <reference anchor="Hlavacek2013" target="https://ripe67.ripe.net/present
<front> ations/240-ipfragattack.pdf">
<title>DNS Glue Requirements in Referral Responses</title> <front>
<author fullname="M. Andrews" initials="M." surname="Andrews"/> <title>IP fragmentation attack on DNS</title>
<author fullname="S. Huque" initials="S." surname="Huque"/> <author initials="T." surname="Hlavacek" fullname="Tomas Hlavacek">
<author fullname="P. Wouters" initials="P." surname="Wouters"/> <organization>cz.nic</organization>
<author fullname="D. Wessels" initials="D." surname="Wessels"/> </author>
<date month="September" year="2023"/> <date year="2013"/>
<abstract> </front>
<t>The DNS uses glue records to allow iterative clients to find the addres <refcontent>RIPE 67 Meeting</refcontent>
ses of name servers that are contained within a delegated zone. Authoritative se </reference>
rvers are expected to return all available glue records for in-domain name serve
rs in a referral response. If message size constraints prevent the inclusion of
all glue records for in-domain name servers, the server must set the TC (Truncat
ed) flag to inform the client that the response is incomplete and that the clien
t should use another transport to retrieve the full response. This document upda
tes RFC 1034 to clarify correct server behavior.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9471"/>
<seriesInfo name="DOI" value="10.17487/RFC9471"/>
</reference>
<reference anchor="RFC2308"> <reference anchor="Fujiwara2018" target="https://indico.dns-oarc.net/eve
<front> nt/31/contributions/692/attachments/660/1115/fujiwara-5.pdf">
<title>Negative Caching of DNS Queries (DNS NCACHE)</title> <front>
<author fullname="M. Andrews" initials="M." surname="Andrews"/> <title>Measures against DNS cache poisoning attacks using IP fragmen
<date month="March" year="1998"/> tation</title>
<abstract> <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara
<t>RFC1034 provided a description of how to cache negative responses. It h ">
owever had a fundamental flaw in that it did not allow a name server to hand out <organization>JPRS</organization>
those cached responses to other resolvers, thereby greatly reducing the effect </author>
of the caching. This document addresses issues raise in the light of experience <date year="2019"/>
and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t> </front>
</abstract> <refcontent>OARC 30 Workshop</refcontent>
</front> </reference>
<seriesInfo name="RFC" value="2308"/>
<seriesInfo name="DOI" value="10.17487/RFC2308"/>
</reference>
<reference anchor="RFC2782"> <reference anchor="DNSFlagDay2020" target="https://dnsflagday.net/2020/"
<front> >
<title>A DNS RR for specifying the location of services (DNS SRV)</title> <front>
<author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/> <title>DNS flag day 2020</title>
<author fullname="P. Vixie" initials="P." surname="Vixie"/> <author>
<author fullname="L. Esibov" initials="L." surname="Esibov"/> <organization/>
<date month="February" year="2000"/> </author>
<abstract> <date></date>
<t>This document describes a DNS RR which specifies the location of the se </front>
rver(s) for a specific protocol and domain. [STANDARDS-TRACK]</t> </reference>
</abstract>
</front>
<seriesInfo name="RFC" value="2782"/>
<seriesInfo name="DOI" value="10.17487/RFC2782"/>
</reference>
<reference anchor="RFC9460"> <reference anchor="Huston2021" target="https://indico.dns-oarc.net/event
<front> /37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf">
<title>Service Binding and Parameter Specification via the DNS (SVCB and HTT <front>
PS Resource Records)</title> <title>Measuring DNS Flag Day 2020</title>
<author fullname="B. Schwartz" initials="B." surname="Schwartz"/> <author initials="G." surname="Huston" fullname="Geoff Huston">
<author fullname="M. Bishop" initials="M." surname="Bishop"/> <organization>APNIC Labs</organization>
<author fullname="E. Nygren" initials="E." surname="Nygren"/> </author>
<date month="November" year="2023"/> <author initials="J." surname="Damas" fullname="Joao Damas">
<abstract> <organization>APNIC Labs</organization>
<t>This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS </author>
resource record (RR) types to facilitate the lookup of information needed to mak <date year="2021" month="February"/>
e connections to network services, such as for HTTP origins. SVCB records allow </front>
a service to be provided from multiple alternative endpoints, each with associat <refcontent>OARC 34 Workshop</refcontent>
ed parameters (such as transport protocol configuration), and are extensible to </reference>
support future uses (such as keys for encrypting the TLS ClientHello). They also
enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR
is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By p
roviding more information to the client before it attempts to establish a connec
tion, these records offer potential benefits to both performance and privacy.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="9460"/>
<seriesInfo name="DOI" value="10.17487/RFC9460"/>
</reference>
<reference anchor="RFC5155"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 900.xml"/>
<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
> 791.xml"/>
<author fullname="B. Laurie" initials="B." surname="Laurie"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="G. Sisson" initials="G." surname="Sisson"/> 035.xml"/>
<author fullname="R. Arends" initials="R." surname="Arends"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="D. Blacka" initials="D." surname="Blacka"/> 471.xml"/>
<date month="March" year="2008"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<abstract> 308.xml"/>
<t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
resource record (RR) for authenticated denial of existence. This document intro 782.xml"/>
duces an alternative resource record, NSEC3, which similarly provides authentica <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
ted denial of existence. However, it also provides measures against zone enumera 460.xml"/>
tion and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
]</t> 155.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.26
</front> 71.xml"/>
<seriesInfo name="RFC" value="5155"/>
<seriesInfo name="DOI" value="10.17487/RFC5155"/>
</reference>
</references>
</references> </references>
<?line 442?> <section anchor="details">
<name>Details of Requestor's Maximum UDP Payload Size Discussions</name>
<section anchor="details"><name>Details of requestor's maximum UDP payload size <t>There are many discussions about default path MTU size and a requestor'
discussions</name> s maximum UDP payload size.</t>
<ul spacing="normal">
<t>There are many discussions for <li>
default path MTU size and requestor's maximum UDP payload size.</t> <t>The minimum MTU for an IPv6 interface is 1280 octets
(see <xref section="5" sectionFormat="of" target="RFC8200"/>).
<t><list style="symbols"> So, it can be used as the default path MTU value for IPv6.
<t>The minimum MTU for an IPv6 interface is 1280 octets
(see Section 5 of <xref target="RFC8200"/>).
So, we can use it as the default path MTU value for IPv6.
The corresponding minimum MTU for an IPv4 interface is 68 (60 + 8) The corresponding minimum MTU for an IPv4 interface is 68 (60 + 8)
<xref target="RFC0791"/>.</t> <xref target="RFC0791"/>.</t>
<t><xref target="RFC4035"/> defines that "A security-aware name server MUST su </li>
pport <li>
the EDNS0 message size extension, MUST support a message
size of at least 1220 octets". Then, the smallest number of <t><xref target="RFC4035"/> states that "A security-aware name server
<bcp14>MUST</bcp14> support the EDNS0 (<xref target="RFC2671"/>) message size ex
tension, [and it] <bcp14>MUST</bcp14> support a message size of at least 1220 oc
tets". Then, the smallest number of
the maximum DNS/UDP payload size is 1220.</t> the maximum DNS/UDP payload size is 1220.</t>
<t>In order to avoid IP fragmentation, </li>
<xref target="DNSFlagDay2020"></xref> proposed that the UDP requestors set the r <li>
equestor's <t>In order to avoid IP fragmentation,
payload size to 1232, and the UDP responders compose UDP responses so they fit <xref target="DNSFlagDay2020"/> proposes that UDP requestors set the requestor's
payload size to 1232 and UDP responders compose UDP responses so they fit
in 1232 octets. in 1232 octets.
The size 1232 is based on an MTU of 1280, which is required The size 1232 is based on an MTU of 1280, which is required
by the IPv6 specification <xref target="RFC8200"/>, by the IPv6 specification <xref target="RFC8200"/>,
minus 48 octets for the IPv6 and UDP headers.</t> minus 48 octets for the IPv6 and UDP headers.</t>
<t>Most of the Internet and especially the inner core has an MTU of at least </li>
<li>
<t>Most of the Internet, especially the inner core, has an MTU of at l
east
1500 octets. 1500 octets.
Maximum DNS/UDP payload size for IPv6 on MTU 1500 ethernet is Maximum DNS/UDP payload size for IPv6 on an MTU 1500 Ethernet is
1452 (1500 minus 40 (IPv6 header size) minus 8 (UDP header size)). 1452 (1500 minus 40 (IPv6 header size) minus 8 (UDP header size)).
To allow for possible IP options and distant tunnel overhead, To allow for possible IP options and distant tunnel overhead,
the recommendation of default maximum DNS/UDP payload size is 1400.</t> the recommendation of default maximum DNS/UDP payload size is 1400.</t>
<t><xref target="Huston2021"></xref> analyzed the result of <xref target="DNSF </li>
lagDay2020"></xref> and reported that <li>
<t><xref target="Huston2021"/> analyzes the result of <xref target="DN
SFlagDay2020"/> and reports that
their measurements suggest that in the interior of the Internet their measurements suggest that in the interior of the Internet
between recursive resolvers and authoritative servers between recursive resolvers and authoritative servers, the prevailing MTU is 150
the prevailing MTU is 1500 0
and there is no measurable signal of use of smaller MTUs and there is no measurable signal of use of smaller MTUs
in this part of the Internet, and proposed that in this part of the Internet. They propose that
their measurements suggest setting the EDNS0 requestor's UDP payload size to their measurements suggest setting the EDNS(0) requestor's UDP payload size to
1472 octets for IPv4, and 1452 octets for IPv6.</t> 1472 octets for IPv4 and 1452 octets for IPv6.</t>
</list></t> </li>
</ul>
<t>As a result of discussions, <t>As a result of these discussions,
this document decided to recommend a value of 1400, this document recommends a value of 1400,
with smaller values also allowed.</t> with smaller values also allowed.</t>
</section>
</section> <section anchor="minimal-responses">
<section anchor="minimal-responses"><name>Minimal-responses</name> <name>Minimal Responses</name>
<t>Some implementations have a "minimal responses" configuration setting/o
<t>Some implementations have a "minimal responses" configuration setting/option ption that causes
that causes
a DNS server to make response packets smaller, containing only mandatory and a DNS server to make response packets smaller, containing only mandatory and
required data.</t> required data.</t>
<t>Under the minimal-responses configuration, <t>Under the minimal-responses configuration,
a DNS server composes responses containing only necessary RRs. a DNS server composes responses containing only necessary Resource Records (RRs)
.
For delegations, see <xref target="RFC9471"/>. For delegations, see <xref target="RFC9471"/>.
In case of a non-existent domain name or non-existent type, In case of a non-existent domain name or non-existent type,
the authority section will contain an SOA record and the answer section is empty the authority section will contain an SOA record, and the answer section is empt
. y
(defined in Section 2 of <xref target="RFC2308"/>).</t> (see <xref section="2" sectionFormat="of" target="RFC2308"/>).</t>
<t>Some resource records (MX, SRV, SVCB, and HTTPS) require
<t>Some resource records (MX, SRV, SVCB, HTTPS) require additional A, AAAA, and Service Binding (SVCB) records
additional A, AAAA, and SVCB records in the Additional section
in the Additional Section defined in <xref target="RFC1035"/>, <xref target="RFC2782"/>, and <xref target=
defined in <xref target="RFC1035"/>, <xref target="RFC2782"/> and <xref target=" "RFC9460"/>.</t>
RFC9460"/>.</t> <t>In addition, if the zone is DNSSEC signed and a query has the DNSSEC OK
bit,
<t>In addition, if the zone is DNSSEC signed and a query has the DNSSEC OK bit,
signatures are added in the answer section, signatures are added in the answer section,
or the corresponding DS RRSet and signatures are added in the authority section. or the corresponding DS RRSet and signatures are added in the authority section.
Details are defined in <xref target="RFC4035"/> and <xref target="RFC5155"/>.</t > Details are defined in <xref target="RFC4035"/> and <xref target="RFC5155"/>.</t >
</section>
<section anchor="impl">
<name>Known Implementations</name>
</section> <t>This section records the status of known implementations of the propose
<section anchor="impl"><name>Known Implementations</name> d recommendations described in <xref target="recommendation"/>.</t>
<t>Please note that the listing of any individual implementation here does
<t>This section records the status of known implementations of these best not
practices defined by this specification at the time of publication, and any imply endorsement by the IETF. Furthermore, no effort has been made to
deviation from the specification.</t> verify the information that was supplied by IETF contributors and presented here
.</t>
<t>Please note that the listing of any individual implementation here does not <section anchor="bind-9">
imply endorsement by the IETF. Furthermore, no effort has been spent to
verify the information presented here that was supplied by IETF contributors.</t
>
<section anchor="bind-9"><name>BIND 9</name>
<t>BIND 9 does not implement the recommendations 1 and 2 in <xref target="Recomm
endationsResponders"/>.</t>
<t>BIND 9 on Linux sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with a fallback to
IP_PMTUDISC_DONT.</t>
<t>BIND 9 on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG is disabled
.</t>
<t>Accepting PATH MTU Discovery for UDP is considered harmful and dangerous. <name>BIND 9</name>
BIND 9's settings avoid attacks to path MTU discovery.</t> <t>BIND 9 does not implement R1 and R2. <!--<xref target="Recommendation
sResponders"/>--></t>
<t>BIND 9 on Linux sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with a fallb
ack to
IP_PMTUDISC_DONT.</t>
<t>For recommendation 3, BIND 9 will honor the requestor's size up to the <t>When BIND 9 is on systems with IP_DONTFRAG (such as FreeBSD), IP_DONT
configured limit (<spanx style="verb">max-udp-size</spanx>). The UDP response pa FRAG is disabled.</t>
cket is bound to be <t>Accepting Path MTU Discovery for UDP is considered harmful and danger
ous.
BIND 9's settings avoid attacks to Path MTU Discovery.</t>
<t>For R3, BIND 9 will honor the requestor's size up to the
configured limit (<tt>max-udp-size</tt>). The UDP response packet is bound to be
between 512 and 4096 bytes, with the default set to 1232. BIND 9 supports the between 512 and 4096 bytes, with the default set to 1232. BIND 9 supports the
requestor's size up to the configured limit (<spanx style="verb">max-udp-size</s requestor's size up to the configured limit (<tt>max-udp-size</tt>).</t>
panx>).</t> <t>In the case of R4 and the send fails with EMSGSIZE, BIND 9
sets the TC bit and tries to send a minimal answer again.</t>
<t>In the case of recommendation 4, and the send fails with EMSGSIZE, BIND 9 <t>For R5, BIND 9 uses the <tt>edns-buf-size</tt>
set the TC bit and try to send a minimal answer again.</t>
<t>In the first recommendation of <xref target="RecommendationsRequestors"/>, BI
ND 9 uses the <spanx style="verb">edns-buf-size</spanx>
option, with the default of 1232.</t> option, with the default of 1232.</t>
<t>For R7, after two UDP timeouts, BIND 9 will fall back to TCP.</t>
</section>
<section anchor="knot-dns-and-knot-resolver">
<name>Knot DNS and Knot Resolver</name>
<t>Both Knot servers set IP_PMTUDISC_OMIT to avoid path MTU spoofing. Th
e UDP size limit is 1232 by default.</t>
<t>Fragments are ignored if they arrive over a Linux XDP interface.</t>
<t>TCP is attempted after repeated UDP timeouts.</t>
<t>Minimal responses are returned and are currently not configurable.</t
>
<t>Smaller signatures are used, with ecdsap256sha256 as the default.</t>
</section>
<section anchor="powerdns-authoritative-server-powerdns-recursor-powerdns-
dnsdist">
<name>PowerDNS Authoritative Server, PowerDNS Recursor, and PowerDNS dns
dist</name>
<t>BIND 9 does implement recommendation 2 of <xref target="RecommendationsReques <ul spacing="normal">
tors"/>.</t> <li>
<t>Use IP_PMTUDISC_OMIT with a fallback to IP_PMTUDISC_DONT.</t>
<t>For recommendation 3, after two UDP timeouts, BIND 9 will fall back to TCP.</ </li>
t> <li>
<t>The default EDNS buffer size of 1232; no probing for smaller size
</section> s.</t>
<section anchor="knot-dns-and-knot-resolver"><name>Knot DNS and Knot Resolver</n </li>
ame> <li>
<t>There is no handling of EMSGSIZE.</t>
<t>Both Knot servers set IP_PMTUDISC_OMIT to avoid path MTU spoofing. </li>
UDP size limit is 1232 by default.</t> <li>
<t>Recursor: UDP timeouts do not cause a switch to TCP, but "spoofin
<t>Fragments are ignored if they arrive over an XDP interface.</t> g near misses" may.</t>
</li>
<t>TCP is attempted after repeated UDP timeouts.</t> </ul>
</section>
<t>Minimal responses are returned and are currently not configurable.</t> <section anchor="powerdns-authoritative-server">
<name>PowerDNS Authoritative Server</name>
<t>Smaller signatures are used, with ecdsap256sha256 as the default.</t> <ul spacing="normal">
<li>
</section> <t>The default DNSSEC algorithm is 13.</t>
<section anchor="powerdns-authoritative-server-powerdns-recursor-powerdns-dnsdis </li>
t"><name>PowerDNS Authoritative Server, PowerDNS Recursor, PowerDNS dnsdist</nam <li>
e> <t>Responses are minimal; this is not configurable.</t>
</li>
<t><list style="symbols"> </ul>
<t>IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT</t> </section>
<t>default EDNS buffer size of 1232, no probing for smaller sizes</t> <section anchor="unbound">
<t>no handling of EMSGSIZE</t> <name>Unbound</name>
<t>Recursor: UDP timeouts do not cause a switch to TCP. "Spoofing nearmisses" <t>Unbound sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with fallback to
do.</t>
</list></t>
</section>
<section anchor="powerdns-authoritative-server"><name>PowerDNS Authoritative Ser
ver</name>
<t><list style="symbols">
<t>the default DNSSEC algorithm is 13</t>
<t>responses are minimal, this is not configurable</t>
</list></t>
</section>
<section anchor="unbound"><name>Unbound</name>
<t>Unbound sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with fallback to
IP_PMTUDISC_DONT. It also disables IP_DONTFRAG on systems that have IP_PMTUDISC_DONT. It also disables IP_DONTFRAG on systems that have
it, but not on Apple systems. On systems that support it Unbound sets it, but not on Apple systems. On systems that support it, Unbound sets
IPV6_USE_MIN_MTU, with a fallback to IPV6_MTU at 1280, with a fallback IPV6_USE_MIN_MTU, with a fallback to IPV6_MTU at 1280, with a fallback
to IPV6_USER_MTU. It also sets IPV6_MTU_DISCOVER to IPV6_PMTUDISC_OMIT to IPV6_USER_MTU. It also sets IPV6_MTU_DISCOVER to IPV6_PMTUDISC_OMIT,
with a fallback to IPV6_PMTUDISC_DONT.</t> with a fallback to IPV6_PMTUDISC_DONT.</t>
<t>Unbound requests a UDP size of 1232 from peers, by default. The reque
stor's
size is limited to a max of 1232.</t>
<t>Unbound requests UDP size 1232 from peers, by default. The requestors <t>After some timeouts, Unbound retries with a smaller size, if applicab
size is limited to a max of 1232.</t> le, or at
size 1232 for IPv6 and 1472 for IPv4. This does not cause any negative effects d
<t>After some timeouts, Unbound retries with a smaller size, if that is ue to
smaller, at size 1232 for IPv6 and 1472 for IPv4. This does not do the "flag day" <xref target="DNSFlagDay2020"/> change to 1232.</t>
anything since the flag day change to 1232.</t>
<t>Unbound has minimal responses as an option, default on.</t>
</section>
</section>
<t>Unbound has the "minimal responses" configuration option; set default
on.</t>
</section>
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>The authors would like to specifically thank <contact fullname="Paul
Wouters"/>, <contact fullname="Mukund Sivaraman"/>, <contact
fullname="Tony Finch"/>, <contact fullname="Hugo Salgado"/>, <contact
fullname="Peter van Dijk"/>, <contact fullname="Brian Dickson"/>,
<contact fullname="Puneet Sood"/>, <contact fullname="Jim Reid"/>,
<contact fullname="Petr Spacek"/>, <contact fullname="Andrew
McConachie"/>, <contact fullname="Joe Abley"/>, <contact
fullname="Daisuke Higashi"/>, <contact fullname="Joe Touch"/>, <contact
fullname="Wouter Wijngaards"/>, <contact fullname="Vladimir Cunat"/>,
<contact fullname="Benno Overeinder"/>, and <contact fullname="Štěpán
Němec"/> for their extensive reviews and comments.</t>
</section>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA8Vc63IbR3b+30/RoX5YKgMQwJtIVqWyEC8WLVHkApS9ictl
DzANYMzBDHZ6hhTE8pPsn+RZsnmvfOec7rkBlLSbZKMqW+Rcuk+f63cuo263
q/Ioj82JvrzRF1kwX5okD/IoTfTwPo3CIJkaHSX67P1Yp/cm0x/OblQwmWTm
/kQH9ER3Vn9Lhek0CZZYL8yCWd6NTD7rholNV90tT3d3+0rZPEjCX4I4TfBW
nhVGqWiV8Y823+33j/u7KshMcKLTlcn4PavuHkBxkpssMXn3jLZS0yA/Aamz
VE3xhElsYd16NsfrS7xwfnuh1Co6UVrn6fREr42VH0Ozyhcneh+/2TTD4zPr
79r1svpVBUW+SDNaoIv/NPbDnbc9fVH8Fj0EWcAXhQFvg09FkmZR816azU/0
98EqSPTIzCOQttZjk91HU2P1adrr6Hd52ONHPZu/vxmN+QKdw+CQp4tonYaB
vogym+vXcTjv6fMAPw72Ljp6r3vUHej3kV1E3bdgreybYbM0Kd/t3hUdfZve
rVO+O01DUDzoD7r9/uGBu1QkIM4Ry5dWC5bRt0cDvacPdgcH+mj/YMC3zDKI
4hM9c0f9w2+rzPamae+3FbFKV7y66ekfoo+RqTHqJiji2kXm0PDHMdgyLbIo
X9eZ0eDDYLDf7+t3gX6T4ph6lAahkI6XTvSPaRraKDQdfTqsHfJ4v3+42zzh
hyTKTajHUEoIIZ3p4dJk0TRoHHqgDw/6eu94D/8d79cPvQL9f8hMOAmypAfq
lYLYl1DUe3MCXYZGlr9p/TqDSKDWg6MT4Yozv52zFKsl+ocghtWRkn/7rb5I
M30V5VfdkbFRHMFs9M3byx1hSKmJ9Kfr/nZcvuq5jcrLwuqrILsrbPsecxzG
XySLdAYbv0wsqCpyo0G6iMHgojsHXMOtmS6SNE7n0N3L244+C7IlzDjMO/o7
g4eStdpO120Pz0Ytom6jIPmI/+aNe/84ooY9/TY2UdIia7iM8taNfxxNb3p6
vCjiZdCm6k2wDjZu/ePogmL9GERhYrK2ZkXTRWDijbv/F6TRurAR7Ep2JC4B
BgsbwTrwJ1k6NSaMkjkbc74w/Jwenl5hye/Gw1M42gTEGApu2PI0Xa5AUaZh
FfTLskhg/RxoKieEbd6Y7NPEZHOstnfSMN5m5MTq5HjgEvRNGtk0SQv7FUYL
PfQ7bKpi1r73dytMnVWX5+fnm8yon59Y8t7kD2l213TIpQD2mDVxcB9MzV2N
NUE2Jye9yPOVPXn5MotW5vBVj/7qIWi/XGXGeo7Zl7v7/W60InAQ5Hkwveut
wlmDw4AnDeig5TmiGNjkK7gL1+OJbPsfeF67eZM1d/qpB160D9xm4+jy5lwf
vtJXCEtQO2KID/rs6esnuTKBhc6Ds3P4ewTtaTCFhq5YUfCyO5jVhaXfNs4t
YOzL522Dkuq824FJeeQKbtROeD0cneq9PoJqdmcX6arJkWM6Mai6iIP5WbDe
7e/2G2cm9DjDPbyx1nR3q4YAJtJDeIYVhJ57yboFHJgm+HWwhZHEI1qetoav
qC3/We5813PLtnjznUlns/YtQSQ37y9PATYmdvuK31NogyK1Fvw+DdLWjW3L
bfJ6fxuvL8ykp/c7dMiBUt1uF7gIaCiY5krdQose4HbitQKcjdM13M85WNPX
MxPk5GahOuQMiV0mCSYxKSH/lpmpiQjd5ykeCsn4jYpy62+EBPv10lgbzI22
0ScDrV0FhLM6+mEB169tsVoBOVveAYZN7hfeV8UkZH4dOr8iYG71ZO32xamx
a0+944dw5WVtHxAHmpcp/hdHdzgWUTcxpTmYUJFz2jCQBYzZfFylFmQ/mOAu
wXJYDIcPVqvYOTa9ylLg/jS2PXWZ68jCAK2NwBPahVOVp0yPyI8jgAM6IZ3W
H0wxYx4W8KXlah12oDaaJ8B17vkEwYl2KVbzLAjpQOmSOYRrt6c3CvJMLDHT
rZVACOBItu5BxqAUKVZBROnQ2GkWTXC4nIJm9OeCfvwC+T3Rm2UUhjFSLSRR
WRoWU37i8VlU+/V39c/0R7V2fQB/4T3mEY4EoeANSFtOBOkE+vXpTUdPCpBX
EDOVy9pweLu2uVkKR9LpncmR0fG+zE6JBB3cWhoXtxX0D+EI67totAjuwY80
RzKWa/Kf2Be5XdxFfIpDEjvZEUUybKJyYt+MFIjYXh6AhF1MYiRIeBuHqaGP
IPbqALuju4ksOqX8IF8EACF0+taJJEpGy1VsSm5DB+/T+N501AOZZRwzuaLO
NTIfonzhlKhxUtGbVYw0EXx15OKaKlbkCcLqNAEZ8WuDQHJaZBmnCOQPkE9C
0qSuZA9YRlzB4+M/jS5OD4+OB7//DkMDZksiu+z9PzmP/w3fUa9MYP/7iHK4
Dd2HJcH+kaqx2kG+vHZGMuVzqavbD6R0rHyJwzvuyPLSN9CaIF+AqRelA2JC
mvSxhopaRNOa//F+UjyTEpGTweYpc45WaiMBdgyIR13a2OECg7xaPR8bA1EC
6EIOy+tZA35CsAStofkC6kQ7Q5MjWbW9F0o9Pv4LdODouN/Ho1aSXtLtDa4p
7w3wAN1ACpqzF/aVFz2tg0XRosp7gZ10Ku/OVSklBLUC1poHd7DTKafhHqin
E5KrsyCmLRQxgDyv8hAB3KR4OduSM9TDGv6dGAhTCchBpU6G7pwUV+wS3gt5
CisA2AVZBDGdjai4Cj5Gy2IJwMtL6TEp7fOr8fhFT1FObiAoOSj8FpHo9uyI
BtPT7jxgKXGf6F0YOPvMkvLdJelD0uHw5R5yiumsIyFPOl1AUdj874xZaSSj
5CycTkJvoiVzhxTXL5SSx4N5hlBWUOviBfEZShDeB+DSvCTNxAEWYTPEFVD4
jVVCRvSJmLeiNMpacjCgYZE+6GWBY0NnC/I/xFr2azNQxjyW2PYxV44bPegJ
NAQ6hI06jRIiOyVoE4Acr4RAuJTD16giFx4zFAbAiuYLt82lZyUf20UQepdC
BywOZMIZLkm5yNtKNZB16r7iG441SRGjgPmjmLwZU7UK1nEaQJzgA7lP8Zav
Xh0etiwlIH9ukOci9KyKjEyaUXk7Blx9GN9696YnEA9v4zWiNBXnqfn3QEKx
dbmW89hHx/sHoEF+2T3eI/cdpiCHcAzCk/LZhLhQ924W2TvOgRtG0gEfp3ER
OiHT65S0wPmbuVhR6c56+jWY1CBBJLfkipkDVBNxDIj3irUVP1JhMwIIkNX+
XEQZs8V6VaWAUmpANMNlvMSBhx5TILl+1F4bg1TI5z7IIqTXX4WAaFkRszgD
D4iaaxM8yKAkWQR0408ouJCEVFhOk4nP8zidwGl4b9gjNFVT+IADBhuo+C9z
H7EKsV9vwBvw8j6IgZeWrOcTcoS5wJt8kaXFfMHqh4iC5WfRvMicJCUKKjzC
Dg/uIUeogYsK9KzguA1RTMns1iXk7SGlSh8MroHGMISwKdOEJ8TJZ9BsaEyR
UwFDlGkKuCM+o84lkuMS6dbEPVVMfiM1JF2TfS1QUzTzdQSSoMmWkavsPD7L
q98czvRY07AGIQDDue+QAe105G/9/pp/Hp3/8cPl6PyMfh6/Gb57V/4gTyj8
cv3hnbtPP1Vvnl5fXZ2/P5OXcVW3Ll0N/3WHsZfaub65vbx+P3y3IwGocfjM
OLhL6DdbZSYXKOn1koOWAhIe7HtFHgyOSwM+Grzaxy8ESgTopUm8dr+Cm6x2
Jsg4Z4ljBbgEeBxbBp8Ing9IcmBB4OnOyGOIHQn41ocwJz+oHQEqwmoObkD6
eIvsGy50R1VvIepIysxQnFAM61aHcFyRWboCVSFMm5GCSaxh2JIusRqZLe8n
ziPkNXlHlr9+/sciJS6x8m+CUeCSnRtnLjtkg3QIaAjHYaROd9ohNHK9dI+u
SVbHZqYmAG2GQZ5Ni2xKaULIaQCuhERFIr6NLreocULZ7Qsdly1xS1QnhdUl
iZVZ7ThvCoDDDv4UAcxC7WO9+awW6AVVwE6dxr6idDcu/gqp74I1WLx1GX7x
6PiYfeMVeU8X1dnskGt+ItcBkqmO5DFUW4VDM2MXEyUcfhoGKjvsux3gL76c
Fz8+ayYxbbu2G1kOU+ETSEWolaRjJSvy3vXGOynqzYjjrTzuTRYhspeQnTJT
HafE/fIK7UGh3jNoqz/riedZGhhA+OUk2rHPG/vExOnDiQI1qdQdRq1z0tGq
PIFh4OOz1kOlUdrfKUP/0h+lRoNee1GHrClDpjh1eXN/2KK/1Lk+C3a0+9Qa
PtCwf4+yMtUlMJ0heCTSP2qu3gqwnHX5hC5DeI8oEUIcuo8o5EW5w7pS4YIP
0TaYIQftaRGGS09FHtNFhG1FbIj6cJLTLAU+DaMZZzpCz0Zu3uNqLPj/enzW
pULS5iMdj8J3ztLkm7zsg0vN8vnZxQs9iXKqMf8E3vVfHQ9+9iCdjatiSZMd
LQD8LkqKj9xRFk6GKQtKMkLyUgBJ01wPby5ZX/igHlySH3M4ipGDFhwyq7xD
o6Ji9fPLm19w+Zezy/Hp9Q/noxdE5TJIkACottSsyYkdcNIlLogYBwHOAp0i
baCXQauLKJz/E2TQpGH7FQ1npYfyCg9zmbqyBB9f465lAiMqfE6rTskiyJaz
IpZkNUiQnAPW9VhyXDRxCWxH4hwR9PhIcJvUGHKHKu89rcpLZqKHtc1sUPKX
RrxJqffACRWrVlil6kisli45bCQMlLrUw1nHLcD4YIZsgvjjL/r6ArFMYF9p
bCFlsPQMpYixCat0zb8k2ptm4ASW85lfDcaUBPp6aoNIapkTw1wJwXHV1QyY
0VFVDqNqwWgfaiwkNLhLAoG6cm0pghsLCdtqk2Vp5stAoiLMZP+6y3PNR+rQ
WVde8RpMOZxjUXMrApqwjczQFl+U4saCoKiss92eki2TyrNjID8zDQpnYQbi
npaRwj1Krr5IyBXNIR4R8qC/d8D+8ys8vtOcrR7f3/taj3/Qay/qVJwzMt2o
Kn1GVSlN2672W3T2azV2U0HV36mdQ1+dccdyeQYuwT2FZfnrK3T38Al+vaQl
Q8iu1k0oKaqKeaQ1BB0u6SJgnVlO4jVPDDl48FTv7jlrZGYeCK3OoD1E0QuK
t696rmjq93CHI2JWwsw25iBzrVSF9FFpXU8dCfJTPIwJFQl2r6pwZaNDc4Qq
qGj/JcXlUo0X44beXvs7NYAnIK/s49TOx7nSekWIOF77fkkRs5V9opDfyGiB
6Ey6iqmNUpW9a1Ktl6Gd6ltj7pqLWLcFSQTPszLVahpSwvsYUK2mA5EcQUk4
AHutS4rlhJKcGffwXB5EQGJ0/PSjw5dD/NGjkbAQ4VwGemgJenXQl3fZ2IK4
W3GoQTv1K8dUhG6XkriwHOhv3PvVeb5pLuArYuwV2bVZac76cwgQuNviSN2h
OoxZQDuX4SkzXdIYGSS+dhHHIRFXBXz++LhxKCRSfOhBm2HcCuMCwUuR75TT
fbb+IJ5T9rlYeiUcn5/21Ps0B9xY+9qqf53e4NrW+enZeMhknYf4SdWqu768
nwpWIqrhvQiMTLP1Kk/nWbBagAIaKEvmiBDScx+Nh1TLYQhE6DKakr6CbRTy
KEfiA7n6hi5gt95TEd2jo44eHUs+BwZIL0zwlC1oMZ7jiiSTrbTAF4UaoiJb
5+SiUVge7fFxEQ3Yjtm8GeTEEc9relTlNOfxmfcBDYNVivVsW85vfa2qRRVN
agYZVzpmKXlji6Snqz+zDsTl+2+S838VkhIdg5gTvaUH1NM/1acrfv4CCQ5m
+ypsu/A6pqJ2kiZdz0Aqv8HYIogSIJ9enZD7a1skoYqG4XGhGStTCc4BeLax
Ek9QrZGg1AxRq5ACaOUOWb3FapV/gAvZiA2c0EpG76rsDXIr/3Q5fD8sp49K
6eOhoOWqvQo8nri7zRKoE5LFRprXlKI0beFngDa38VVn3zbG2v4SceZ3pa4T
6WS1csaEswhVwzkOb7ayMZ+IEeNYoibvqHTrmhRUF1REK5cXMBKbgJl4X8RU
vOfCNeekZWEtSj7TWOupWx/5KTvrtOoZenTIzX3rioOUHBLUosINmQ2dqYY3
ajFS9B0xHOEfCkp85qBFeMvhqjp/fuRuJtEhbcJ6cV8FNSDjG4zQ6IgrYba9
LLOqakgrnkOIloZKwL5n+cBxFv6+gHPBkxyN6WGiWx6hVTxzycKojjyhOS7R
LFnBd4epvs4dSuevihULqX0QWTmy9SxRGOtyReIt19wY9Vd0yYRB7vsSVDSs
Jj9wKsgLkI0r5fTkHCQ9BGto99CzdLN/TJ0uOIAM6W2tgADKwkgMgPJeHLoC
vXWCpBX6ktuAAVUtKZexbsCA16aQiwTZSBddbvfYEoKG96u1sD1kJEhEDi2C
ORQrKeWGtR5PHZxbGZqbueQUtFNc7yhOBmRX8UpuvO4BMkP0IXdWodx2msEo
GMT+WE3bYIcNHj4+e8Ku6qr9NaOU+qf6JObPXJnwyRs8vypb5tua6u5g93iW
wO32Kbue+tLAIWiojTz+zCzfNsOtnpjh1j9Vk+D+BAzZNvv9impNnJQBwJuN
LLddFpbqMtmGS2y3RkWuWXFvf6tL6pW9z71j3/tktVZlc5HCYTkmCnmvIKRo
mnOvzC+pITvotW8DSe5opVE2NtLp3Ovt6udXbjxkTG2L7wqaRAHMsi98RfED
361u+Dpm/wh5OI3YSEsmdkwMmsNeVReIq5G8om8727JrQSAvSqpuvKssSK2i
MRdwK61/S5Us/noAB7j98ELRRyzzSjouWte6Dzj5sD4UUQ3POKjBH73UJdIg
tdaYdMNVDAvZpwdLP0dhaGpjta7qrAgqDLEI/kjCIiGnRojygjJUWOL5Bqwk
HnhiykRgcEgBmNsu0nGnZdgFy4iekmedis74+5RSF8gPl+5r1kYBU2oy9dTr
NSNZHNKm0g3jeOIRrHNgXFSlnLY+N8G9HhkK2TDegutIl6dXN/r9+fnZxWj4
nU/We6SMtzS01qqKSnpJhQdalJpF5AVrXp3cJQcUntNjUJxRAP26lTLnD6Zr
obwgAOhGH9zKbi6gxFw3rltPX0BVLlMSJYoIgXzTghxFhoy/OGPMCg4noTYd
YFkKJgq2zQawyTEOA8inWctIPC5okSDo6OIxBXrOZbBlWZ/sY26kajVNMy5+
l2Eumin2ev5GjQIqTCe/8UweNQoiK0eHAkdIQdNZ18r3VKqO8tY+IU70OjKQ
BoFsUM0ZPvc1CwdxEXKfYpcr+jspdjzn70t/77G9laBePUuZmh8wdWDaK4Hr
qPqiSj0YvjbiwvONAYX6/CKI2mnMMO6UzyqsufB5cKB3ts4Jdnak92+dQ3aT
+TR/ZVZORzbpZGbQaJEqq2EtVE0AT8JGuiXAVlD6b3itU03YIP2VLPiQ0LIf
NoipUNBoXW3W4Wxt6kWeKOLYK0150jpwJzVc+knzdtlEseIHnJR9MllaJSwI
5ZZaMlQNuqI02N+xiBcul4FTHDRzFL9p2USj5bmTVy78RkbJeuq5y5Q80d/Y
Wr/U50mhEdhdpo/uFHJM2pKKRBwiGvN8XvLUtRMSW1+Isj+UBpVVaaVoWL9T
HoPjxpZoIOYohSZb1vxlsktx2YHj1cEeFXK5HZjanONlUlNHm87yh0CS6QlR
ei/HrKnJK+jHOZATxZzRK8+U8gHYsczWQUOY1goJBG3vIO2NjnLdvrprYIop
A2Klogob0AdPJlmaSKXAP/U9HVaBarjaQzSXJXGPEivYmk4zX++04k8lf0zp
YyXq/1wVdwhsAE33AeBBAPO4TZO1voC+LjrqTTFP9TiI50GYdtQN1a7gqiCe
6Le7jnqdRfwziCe7uimQueZ6nKbwa99HSz0yUchvZXpM43B4ZZhArx701RSo
nNuxeDI1egintoYzDCJbgPQ30Tywi0ju3aYFkSIk6x+j35J5AK2wHfVDDF7R
d02nBbAR6DEAQPoaQgWECEUx1X/9e/7Xv6z+8z8S/f6vf0Hg4BkB8zE3iZtH
uY9AEKmw5OG5dePtlHsiMkqHgIzsq+pOpLOFta6g4fsLqhRUJjhzydNqtWcp
7odmFpDeNLpPZbX0S1sT2dL0dr0YWoHryInYftWUgQIPdo/6QEw5eR+tn1tj
SjR9oMvZOWnyv+hxRblDk5HksimeRDw2Lti0RbV0d2hn2rbnW2QUhbkbR+q9
ncb9Jo2HR/r5YV9/q49eYBEZfKHWObfNuu7CPvfR3CCKCzU7w3KAsRuwbdeq
8I2JStcrlMJiY8DcqQghyMYIZlDiXV1WU7El7Ja+nt7d9Vzd4QkEhz+lmGzz
qtjvNv5sK4vFtNvnw15StTCUrvX2uRJqU/7U/ILqZwpT0qNptFDrzSyz0fPD
Og0ysONgd2+3U3aKWy1y3xtvNr5sKnNos4iYDFdIazjeeJ2Qhh1dJ9/L1QzK
khM/qEVK6itIkS17BnjbNQxZrxtjgg3FJZZA0+BB94/c1mVZlV8NXCa38NEQ
nL5Kq3prOaXOrV03GOWCUZQklHRRUHbfR/jxMq8N2H1w0O/XDn31OXF7iyEe
0FL8rqGYmHC1hpbbP0Cmyzfcufo0poF33DwzLfTC3YP1VGeTO2zJhJqo8u5K
Mg5SQp384IeDEDK1UeCYMZemaCHfXG9VLXFq7wa+qNHcnwWff6o+yqPaRxCv
P7kcuerubeizOEMyRKfTQg9igMtXBBvZYj431iEEl0qya6GiYUu2pE1u8G9z
TNGWidVG/cNxggI5fDw5NRIanRDiqeYqBFggLgmBXNuQj7mIEDeC45tNWMGK
tcjoTpBtqKL7rKdu15/ngRvNeaKBsiGiPGU9e7VbNxiGlrwxa2DzDqHnoYyH
ernVIltH5a2562nkOs6lEuFdCRpk89CPjgBizxUp+UBpbVp18NXVRhf08dlm
E1E1OlVPdER3NjqiO62OqGPiyy2d0fq3RP+Txih3+xptURzyAxcdygmLp5u+
nSYdzidb3Xi8sXH5TSA1nKWjXWXI9BEdT0hQiD3ef8Uxl0bRAlFYyVXMR3gJ
FmrVqNY8glm7l69XBkAzX1R1xHWZKJaFa3odLnR8PWS1yMIy2gSJfSD/5d6A
LpnlKl8jc6mGT0vssivYhaje3esfSQ+ZRU8WzUO9sjzlT3/q6PHoB/zvh9PX
Hf3m9vZm/MIHGYUMKJJcWA87mhrzYgD0sF9DOdcyrJ51hKgabW5il3FKxxP3
6mgXqIUW9Dw+lHFKMNlv3aF8g9bnIQcc3BULXLVEBpNhytmaI5DLy+iJ67eU
GXZU2euWUgsW9oO8bb52lIuLTZx2NoZ2jF0A/OxqbdH2SujcnBNuwraKAQeD
A5mHektfNunLlqU+PuNJvVoP0n3Q4fXCi5XhFt4qGLPzZ1IbZi8uFZo8gRtE
KiZFDFtSyeiC1m4gCwegqLXFxWoePXAfUbAsEvrykZrenNn6tndjESriEDgw
tVlIGUW3uXyyyN+xUJvrPgrpe7JWy5gDiq+HcSljTc0oQDnJVT0wOr+9oK/3
M4pANNfUoRBkZjOCsKQsE4p3II0HMxVcRjTzsKaalHFlHBqtNJmjlr7dJSyM
RFlGjbCTFFPpY52UQdTry/dn+liVNSj+tariVZn1JpRA+GRm7oqqPD3g/Hu5
D+ElmQy15GlbU6tSA/rlBtfo0i/XV5e32tVbfIuRWFB/5uz6/W1jeT9v6wop
/AAXgJ9b6v2DJReZMa/HZy86jds8/WEp5oecvk/NisV8M7x989S4a6NZuX2k
1VH2jS3nbl1OUBZl0y3NHfrulOuFDei219HunOyLF2lSzh1UKIGRgTQGqYFT
m9yToZXnvwL2dYtw1aUnf30h09dPNB0nKVUcuA1bfnJxMNjlM+73jw+hVTl/
7eoHLj205FxFkpGeJ7r+4a96mmT9ZZLdVxumjHEtRu1XCRB3gGbs3JjI86vx
d+PLfzv3rFQ+q/Lzn/Rext+9WoE7HnA4J8xF9ooCqXNtYuwt9lCOf/5eyrHw
DdhfTZjY7qSYyRGVgJctjOVUC0xtmmplpi1Kdr9Iy5OqFsyoiJM/pLo5JVBX
QbJK7czSjTK8JbfBH02Ae/zLyBcfnYuhBtJbGemQ7iSJYMPuy+S5KrGs0hRO
f97jsQVWGtEPTr6RmU7Wnk2177bdZyc8mRS6KA0Al2WUH/AXqsAyf+LhdVfP
cF8cU5shzwnAUABnZiCdMYHv03mOVPi21S2RmSYf/XHBzcYToEvzChPC5fgR
kPrInCxCUyVODcw0tMFq9+DQLgL8v1XU4Z4DFJRYP2wkQWP3ZVd5e8S5U1q/
BO2jNNKJqPuEG645Yd12wnjJ6+g5/7sZBU3Tl3UXKUsk3Iee8BwLlK4aE/wE
dN6l2wswK3bh1dsq7niSTxqs99NervWtLaicLrwu6p2x0xgAaDjnyHK2EKZf
YlXJhbrhObhWTS2S1u3hoabQnbfoCCpx5ee6qClRYLfqdnG//Y0B8bPhUF/m
koG5gGYbga4WIxklUGKlgEB5cpGopX8NckVTuf6bGn3desUX2GB7dfJByQ+H
v3wYn/9ydfmeDtLZEr01P8Tfsee+atR8SPmHsNKInqwO5JgkC7TYhIsNRqmn
9m5jB3+Ecg6udC/sVaQ7YbgGX/MwHDar6pzyRRP/tTT5L6qw1Dz2kJ0I/6MT
lTutds/pHwXyzKibhksuAq4sldlpkNeJ9AUpSfxflVf2XdO0RHRhqgBb6Z8W
mON9amxzGPP/XpN8+VDG7oo7hEQ3cm/XkPTRqgxSCJD/DUD52a9tVAAA
</rfc> </rfc>
 End of changes. 86 change blocks. 
1173 lines changed or deleted 543 lines changed or added

This html diff was produced by rfcdiff 1.48.