rfc9511.original.xml		rfc9511.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-rfc2629 version 1.6.5 (Ruby 2 .7.0) -->		<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.5 (Ruby 2 .7.0) -->
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		<!DOCTYPE rfc [
	-ietf-opsec-probe-attribution-09" category="info" submissionType="IETF" tocInclu		<!ENTITY nbsp "&#160;">
	de="true" sortRefs="true" symRefs="true" version="3">		<!ENTITY zwsp "&#8203;">
	<!-- xml2rfc v2v3 conversion 2.40.0 -->		<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
			]>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
			-ietf-opsec-probe-attribution-09" number="9511" submissionType="IETF" category="
			info" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates=
			"" obsoletes="" xml:lang="en" version="3">
			<!-- xml2rfc v2v3 conversion 2.40.0 -->
	<front>		<front>
	<title abbrev="Probes Attribution">Attribution of Internet Probes</title>		<title abbrev="Attribution of Internet Probes">Attribution of Internet Probe
	<seriesInfo name="Internet-Draft" value="draft-ietf-opsec-probe-attribution"		s</title>
	/>		<seriesInfo name="RFC" value="9511"/>
	<author initials="E." surname="Vyncke" fullname="Éric Vyncke">		<author initials="É." surname="Vyncke" fullname="Éric Vyncke">
	<organization>Cisco</organization>		<organization>Cisco</organization>
	<address>		<address>
	<postal>		<postal>
	<street>De Kleetlaan 6A</street>		<street>De Kleetlaan 6A</street>
	<city>Diegem</city>		<city>Diegem</city>
	<code>1831</code>		<code>1831</code>
	<country>Belgium</country>		<country>Belgium</country>
	</postal>		</postal>
	<email>evyncke@cisco.com</email>		<email>evyncke@cisco.com</email>
	</address>		</address>
	skipping to change at line 40 ¶		skipping to change at line 48 ¶
	</author>		</author>
	<author initials="J." surname="Iurman" fullname="Justin Iurman">		<author initials="J." surname="Iurman" fullname="Justin Iurman">
	<organization>Université de Liège</organization>		<organization>Université de Liège</organization>
	<address>		<address>
	<postal>		<postal>
	<country>Belgium</country>		<country>Belgium</country>
	</postal>		</postal>
	<email>justin.iurman@uliege.be</email>		<email>justin.iurman@uliege.be</email>
	</address>		</address>
	</author>		</author>
	<date year="2023" month="July" day="23"/>		<date year="2023" month="November"/>
	<area>Operations and Management</area>
	<workgroup>Operational Security Capabilities for IP Network Infrastructure</		<area>ops</area>
	workgroup>		<workgroup>opsec</workgroup>
	<keyword>Internet-Draft</keyword>
			<keyword>research</keyword>
			<keyword>measurement</keyword>
			<keyword>identification</keyword>
			<keyword>probing</keyword>
			<keyword>out-of-band</keyword>
			<keyword>in-band</keyword>
	<abstract>		<abstract>
	<t>Active measurements over the public Internet can target either collabor		<t>Active measurements over the public Internet can target either collabor
	ating parties or non-collaborating ones. Sometimes these measurements, also call		ating parties or non-collaborating ones. Sometimes these measurements, also call
	ed probes, are viewed as unwelcome or aggressive.</t>		ed "probes", are viewed as unwelcome or aggressive.</t>
	<t>This document suggests some simple techniques for a source to identify		<t>This document suggests some simple techniques for a source to identify
	its probes, allowing any party or organization to understand what an unsolicited		its probes. This allows any party or organization to understand what an unsolici
	probe packet is, what its purpose is, and more importantly who to contact. The		ted probe packet is, what its purpose is, and, most importantly, who to contact.
	technique relies on off-line analysis of the probe, therefore it does not requir		The technique relies on offline analysis of the probe; therefore, it does not r
	e any change in the data or control plane. It has been designed mainly for layer		equire any change in the data or control plane. It has been designed mainly for
	-3 measurements.</t>		layer 3 measurements.</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	The latest revision of this draft can be found at <eref target="https://
	evyncke.github.io/opsec-probe-attribution/draft-ietf-opsec-probe-attribution.htm
	l"/>.
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-opsec-probe/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	Operational Security Capabilities for IP Network Infrastructure Working
	Group mailing list (<eref target="mailto:opsec@ietf.org"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/opsec/"/>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/evyncke/opsec-probe-attribution"/>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>Many measurement researches (<xref target="LARGE_SCALE"/>, <xref target		<t>Most measurement research (e.g., <xref target="LARGE_SCALE"/>, <xref ta
	="RFC7872"/>, and <xref target="I-D.draft-vyncke-v6ops-james"/>) are about sendi		rget="RFC7872"/>, and <xref target="I-D.vyncke-v6ops-james"/>) is about sending
	ng IP packets (sometimes with extension headers or layer-4 headers) over the pub		IP packets (sometimes with extension headers or layer 4 headers) over the public
	lic Internet and those packets can be destined to either collaborating parties o		Internet, and those packets can be destined to either collaborating parties or
	r non-collaborating ones. Such packets are called probes in this document.</t>		non-collaborating ones. Such packets are called "probes" in this document.</t>
	<t>Sending unsolicited probes should obviously be done at a rate low enoug		<t>Sending unsolicited probes should obviously be done at a rate low enoug
	h to not unduly impact the other parties' resources. But even at a low rate, tho		h to not unduly impact the other parties' resources. But even at a low rate, tho
	se probes could trigger an alarm that will request some investigations by either		se probes could trigger an alarm that will request some investigations by either
	the party receiving the probe (i.e., when the probe destination address is one		the party receiving the probe (i.e., when the probe destination address is one
	address assigned to the receiving party) or by a third party having some devices		address assigned to the receiving party) or a third party having some devices th
	through which those probes are transiting (e.g., an Internet transit router). T		rough which those probes are transiting (e.g., an Internet transit router). The
	he investigation will be done off-line by using packet captures, therefore the p		investigation will be done offline by using packet captures; therefore, probe at
	robe attribution does not require any change in the data or control planes.</t>		tribution does not require any change in the data or control planes.</t>
	<t>This document suggests some simple techniques for a source to identify		<t>This document suggests some simple techniques for a source to identify
	its probes, allowing any party or organization to understand:</t>		its probes. This allows any party or organization to understand:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>what an unsolicited probe packet is,</li>		<li>what an unsolicited probe packet is,</li>
	<li>what its purpose is,</li>		<li>what its purpose is, and</li>
	<li>and more importantly who to contact for further information.</li>		<li>most importantly, who to contact for further information.</li>
	</ul>		</ul>
	<t>It is expected that only researchers with good intentions will use thes e techniques, although anyone might use them. This is discussed in <xref target= "security"/>.</t>		<t>It is expected that only researchers with good intentions will use thes e techniques, although anyone might use them. This is discussed in <xref target= "security"/>.</t>
	<t>While the technique could be used to mark measurements done at any laye r of the protocol stack, it is mainly designed to work for measurements done at layer 3 (and its associated options or extension headers).</t>		<t>While the technique could be used to mark measurements done at any laye r of the protocol stack, it is mainly designed to work for measurements done at layer 3 (and its associated options or extension headers).</t>
	</section>		</section>
	<section anchor="probe-description">		<section anchor="probe-description">
	<name>Probe Description</name>		<name>Probe Description</name>
	<t>This section provides a way for a source to describe (i.e., to identify ) its probes.</t>		<t>This section provides a way for a source to describe (i.e., to identify ) its probes.</t>
	<section anchor="uri">		<section anchor="uri">
	<name>Probe Description URI</name>		<name>Probe Description URI</name>
	<t>This document defines a Probe Description URI as a URI pointing to ei ther:</t>		<t>This document defines a Probe Description URI as a URI pointing to on e of the following:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>a Probe Description File (see <xref target="file"/>) as defined in <xref target="iana"/>, e.g., "https://example.net/.well-known/probing.txt";</li >		<li>a Probe Description File (see <xref target="file"/>) as defined in <xref target="iana"/>, e.g., "https://example.net/.well-known/probing.txt";</li >
	<li>an email address, e.g., "mailto:lab@example.net";</li>		<li>an email address, e.g., "mailto:lab@example.net"; or</li>
	<li>a phone number, e.g., "tel:+1-201-555-0123".</li>		<li>a phone number, e.g., "tel:+1-201-555-0123".</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="file">		<section anchor="file">
	<name>Probe Description File</name>		<name>Probe Description File</name>
	<t>As defined in <xref target="iana"/>, the Probe Description File must be made available at "/.well-known/probing.txt". The Probe Description File must follow the format defined in section 4 of <xref target="RFC9116"/> and should c ontain the following fields defined in section 2 of <xref target="RFC9116"/>:</t >		<t>As defined in <xref target="iana"/>, the Probe Description File must be made available at "/.well-known/probing.txt". The Probe Description File must follow the format defined in <xref target="RFC9116" section="4" sectionFormat=" of" /> and should contain the following fields defined in <xref target="RFC9116" section="2" sectionFormat="of" />:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Canonical</li>		<li>Canonical</li>
	<li>Contact</li>		<li>Contact</li>
	<li>Expires</li>		<li>Expires</li>
	<li>Preferred-Languages</li>		<li>Preferred-Languages</li>
	</ul>		</ul>
	<t>A new field "Description" should also be included to describe the mea surement. To match the format defined in section 4 of <xref target="RFC9116"/>, this field must be a one-line string with no line break.</t>		<t>A new field "Description" should also be included to describe the mea surement. To match the format defined in <xref target="RFC9116" section="4" sect ionFormat="of" />, this field must be a one-line string with no line break.</t>
	<section anchor="example">		<section anchor="example">
	<name>Example</name>		<name>Example</name>
	<artwork><![CDATA[		<artwork><![CDATA[
	# Canonical URI (if any)		# Canonical URI (if any)
	Canonical: https://example.net/measurement.txt		Canonical: https://example.net/measurement.txt
	# Contact address		# Contact address
	Contact: mailto:lab@example.net		Contact: mailto:lab@example.net
	# Validity		# Validity
	skipping to change at line 121 ¶		skipping to change at line 123 ¶
	# Languages		# Languages
	Preferred-Languages: en, es, fr		Preferred-Languages: en, es, fr
	# Probes description		# Probes description
	Description: This is a one-line string description of the probes.		Description: This is a one-line string description of the probes.
	]]></artwork>		]]></artwork>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="out-of-band-probe-attribution">		<section anchor="out-of-band-probe-attribution">
	<name>Out-of-band Probe Attribution</name>		<name>Out-of-Band Probe Attribution</name>
	<t>A possibility for probe attribution is to build a specific URI based on the source address of the probe packet, following <xref target="RFC8615"/>. For example, with a probe source address 2001:db8:dead::1, the following URI is bui lt:</t>		<t>A possibility for probe attribution is to build a specific URI based on the source address of the probe packet, following <xref target="RFC8615"/>. For example, with a probe source address 2001:db8:dead::1, the following URI is bui lt:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>if the reverse DNS record for 2001:db8:dead::1 exists, e.g., "exampl		<li>If the reverse DNS record for 2001:db8:dead::1 exists, e.g., "exampl
	e.net", then the Probe Description URI is "https://example.net/.well-known/probi		e.net", then the Probe Description URI is "https://example.net/.well-known/probi
	ng.txt". There should be only one reverse DNS record; otherwise, the Probe Descr		ng.txt". There should be only one reverse DNS record; otherwise, the Probe Descr
	iption File should also exist for all reverse DNS records and be identical;</li>		iption File should also exist for all reverse DNS records and be identical.</li>
	<li>else (or in addition), the Probe Description URI is "https://[2001:d		<li>Else (or in addition), the Probe Description URI is "https://[2001:d
	b8:dead::1]/.well-known/probing.txt".</li>		b8:dead::1]/.well-known/probing.txt".</li>
	</ul>		</ul>
	<t>The built URI must be a reference to the Probe Description File (see <x ref target="file"/>).</t>		<t>The built URI must be a reference to the Probe Description File (see <x ref target="file"/>).</t>
	<t>As an example, the UK National Cyber Security Centre <xref target="NCSC "/> uses a similar attribution. They scan for vulnerabilities across internet-co nnected systems in the UK and publish information on their scanning (<xref targe t="NCSC_SCAN_INFO"/>), providing the address of the webpage in reverse DNS.</t>		<t>As an example, the UK National Cyber Security Centre <xref target="NCSC "/> uses a similar attribution. They scan for vulnerabilities across Internet-co nnected systems in the UK and publish information on their scanning <xref target ="NCSC_SCAN_INFO"/>, providing the address of the web page in reverse DNS.</t>
	</section>		</section>
	<section anchor="in-band-probe-attribution">		<section anchor="in-band-probe-attribution">
	<name>In-band Probe Attribution</name>		<name>In-Band Probe Attribution</name>
	<t>Another possibility for probe attribution is to include a Probe Descrip tion URI in the probe itself. Here is a non-exhaustive list of examples:</t>		<t>Another possibility for probe attribution is to include a Probe Descrip tion URI in the probe itself. Here is a non-exhaustive list of examples:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>For an ICMPv6 echo request <xref target="RFC4443"/>, include it in t		<li>For an ICMPv6 echo request <xref target="RFC4443"/>, include it in t
	he data field;</li>		he data field.</li>
	<li>For an ICMPv4 echo request <xref target="RFC792"/>, include it in th		<li>For an ICMPv4 echo request <xref target="RFC0792"/>, include it in t
	e data field;</li>		he data field.</li>
	<li>For a UDP datagram <xref target="RFC768"/>, include it in the data p		<li>For a UDP datagram <xref target="RFC0768"/>, include it in the data
	ayload if there is no upper-layer protocol after the transport layer;</li>		payload if there is no upper-layer protocol after the transport layer.</li>
	<li>For a TCP segment <xref target="RFC9293"/>, include it in the data p		<li>For a TCP segment <xref target="RFC9293"/>, include it in the data p
	ayload if there is no upper-layer protocol after the transport layer;</li>		ayload if there is no upper-layer protocol after the transport layer.</li>
	<li>For an IPv6 packet <xref target="RFC8200"/>, include it in a PadN op		<li>For an IPv6 packet <xref target="RFC8200"/>, include it in a PadN op
	tion either inside a Hop-by-Hop or Destination Options header.</li>		tion inside either a Hop-by-Hop or Destination Options header.</li>
	</ul>		</ul>
	<t>The Probe Description URI must start at the first octet of the payload		<t>The Probe Description URI must start at the first octet of the payload
	and must be terminated by an octet of 0x00, i.e., it must be null terminated. If		and must be terminated by an octet of 0x00, i.e., it must be null terminated. If
	the Probe Description URI cannot be placed at the beginning of the payload, the		the Probe Description URI cannot be placed at the beginning of the payload, the
	n it must be preceded by an octet of 0x00. Inserting the Probe Description URI c		n it must be preceded by an octet of 0x00. Inserting the Probe Description URI c
	ould obviously bias the measurement itself if the probe packet becomes larger th		ould obviously bias the measurement itself if the probe packet becomes larger th
	an the path MTU. Some examples are given in the appendix <xref target="examples"		an the path MTU. Some examples are given in <xref target="examples"/>.</t>
	/>.</t>		<t>Using a magic string (i.e., a unique, special opaque marker) to signal
	<t>Note: using a magic string (i.e., a unique special opaque marker) to si		the presence of the Probe Description URI is not recommended as some transit nod
	gnal the presence of the Probe Description URI is not recommended as some transi		es could apply different processing for packets containing this magic string.</t
	t nodes could apply a different processing for packets containing this magic str		>
	ing.</t>		<t>For the record, in-band probe attribution was used in <xref target="I-D
	<t>For the record, the in-band probe attribution was used in <xref target=		.vyncke-v6ops-james"/>.</t>
	"I-D.draft-vyncke-v6ops-james"/>.</t>
	</section>		</section>
	<section anchor="operational-and-technical-considerations">		<section anchor="operational-and-technical-considerations">
	<name>Operational and Technical Considerations</name>		<name>Operational and Technical Considerations</name>
	<t>Using either the out-of-band or in-band technique, or even both combine		<t>Using either the out-of-band or in-band technique, or even both combine
	d, highly depends on intent or context. This section describes the upsides and d		d, highly depends on intent or context. This section describes the upsides and d
	ownsides of each technique, so that probe owners or probe makers can freely deci		ownsides of each technique so that probe owners or probe makers can freely decid
	de what works best for their cases.</t>		e what works best for their cases.</t>
	<t>The advantages of using the out-of-band technique are that the probing		<t>The advantages of using the out-of-band technique are that the probing
	measurement is not impacted by the probe attribution but also that it is easy to		measurement is not impacted by probe attribution and that it is easy to set up,
	set up, i.e., by running a web server on a probe device to describe the measure		i.e., by running a web server on a probe device to describe the measurements. Un
	ments. Unfortunately, there are some disadvantages too. In some cases, using the		fortunately, there are some disadvantages too. In some cases, using the out-of-b
	out-of-band technique might not be possible due to several conditions: the pres		and technique might not be possible due to several conditions: the presence of a
	ence of a NAT, too many endpoints to run a web server on, the probe source IP ad		NAT, too many endpoints to run a web server on, the probe source IP address can
	dress cannot be known (e.g., RIPE Atlas <xref target="RIPE_ATLAS"/> probes are s		not be known (e.g., RIPE Atlas <xref target="RIPE_ATLAS"/> probes are sent from
	ent from IP addresses not owned by the probe owner), dynamic source addresses, e		IP addresses not owned by the probe owner), dynamic source addresses, etc.</t>
	tc.</t>		<t>The primary advantage of using the in-band technique is that it covers
	<t>The primary advantage of using the in-band technique is that it covers		the cases where the out-of-band technique is not feasible (as described above).
	the cases where the out-of-band technique is not feasible (as described above).		The primary disadvantage is that it could potentially bias the measurements, sin
	The primary disadvantage is that it could potentially bias the measurements, sin		ce packets with the Probe Description URI might be discarded. For example, data
	ce packets with the Probe Description URI might be discarded. For example, data		is allowed in TCP segments with the SYN flag <xref target="RFC9293"/> but may ch
	is allowed in TCP segments with the SYN flag (<xref target="RFC9293"/>) but may		ange the way they are processed, i.e., TCP segments with the SYN flag containing
	change the way they are processed, i.e., TCP segments with the SYN flag containi		the Probe Description URI might be discarded. Another example is the Probe Desc
	ng the Probe Description URI might be discarded. Another example is the Probe De		ription URI included in a Hop-by-Hop or Destination Options header inside a PadN
	scription URI included in a Hop-by-Hop or Destination Options header, inside a P		option. <xref target="RFC4942" section="2.1.9.5" sectionFormat="of" /> (an Info
	adN option. As per the informational <xref target="RFC4942"/>, section 2.1.9.5,		rmational RFC) suggests that a PadN option should only contain 0s and be smaller
	it is suggested that a PadN option should only contain 0's and be smaller than 8		than 8 octets, thus limiting its use for probe attribution. If a PadN option do
	octets, thus limiting its use for probe attribution. If a PadN option does not		es not respect the recommendation, it is suggested that one may consider droppin
	respect the recommendation, it is suggested that one may consider dropping such		g such packets. For example, since version 3.5, the Linux Kernel follows these
	packets. For example, the Linux Kernel follows these recommendations and discard		recommendations and discards such packets.</t>
	s such packets since its version 3.5;</t>
	<t>Having both the out-of-band and in-band techniques combined also has a big advantage, i.e., it could be used as an indirect means of "authenticating" t he Probe Description URI in the in-band probe, thanks to a correlation with the out-of-band technique (e.g., a reverse DNS lookup). While the out-of-band techni que alone is less prone to spoofing, the combination with the in-band technique offers a more complete solution.</t>		<t>Having both the out-of-band and in-band techniques combined also has a big advantage, i.e., it could be used as an indirect means of "authenticating" t he Probe Description URI in the in-band probe, thanks to a correlation with the out-of-band technique (e.g., a reverse DNS lookup). While the out-of-band techni que alone is less prone to spoofing, the combination with the in-band technique offers a more complete solution.</t>
	</section>		</section>
	<section anchor="ethical-considerations">		<section anchor="ethical-considerations">
	<name>Ethical Considerations</name>		<name>Ethical Considerations</name>
	<t>Executing measurement experiences over the global Internet obviously re quires ethical consideration, which is discussed in <xref target="ANRW_PAPER"/>, especially when unsolicited transit or destination parties are involved.</t>		<t>Executing measurement experiences over the global Internet obviously re quires ethical consideration, which is discussed in <xref target="ANRW_PAPER"/>, especially when unsolicited transit or destination parties are involved.</t>
	<t>This document proposes a common way to identify the source and the purp ose of active probing in order to reduce the potential burden on the unsolicited parties.</t>		<t>This document proposes a common way to identify the source and the purp ose of active probing in order to reduce the potential burden on the unsolicited parties.</t>
	<t>But there are other considerations to be taken into account: from the p ayload content (e.g., is the encoding valid?) to the transmission rate (see also <xref target="IPV6_TOPOLOGY"/> and <xref target="IPV4_TOPOLOGY"/> for some prob ing speed impacts). Those considerations are out of scope of this document.</t>		<t>But there are other considerations to be taken into account, from the p ayload content (e.g., is the encoding valid?) to the transmission rate (see also <xref target="IPV6_TOPOLOGY"/> and <xref target="IPV4_TOPOLOGY"/> for some prob ing speed impacts). Those considerations are out of scope of this document.</t>
	</section>		</section>
	<section anchor="security">		<section anchor="security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>This document proposes simple techniques for probe attribution. It is e		<t>This document proposes simple techniques for probe attribution. It is e
	xpected that only ethical researchers would use them, which would simplify and r		xpected that only ethical researchers would use them, which would simplify and r
	educe the time to identify probes across the Internet. In fact, these techniques		educe the time to identify probes across the Internet. In fact, these techniques
	could be used by anyone, malicious or not, which means that the information obt		could be used by anyone, malicious or not, which means that the information obt
	ained cannot be blindly trusted. Using these techniques should not mean that a p		ained cannot be blindly trusted. Using these techniques should not mean that a p
	robe can be trusted. Instead, it should be considered as a solution for third pa		robe can be trusted. Instead, third parties should use this solution to potentia
	rties to potentially understand the origin and context of such probes. This solu		lly understand the origin and context of such probes. This solution is not perfe
	tion is not perfect but it provides a way for probe attribution, which is better		ct, but it provides a way for probe attribution, which is better than no solutio
	than no solution at all.</t>		n at all.</t>
	<t>The probe attribution is provided to identify the source and intent of		<t>Probe attribution is provided to identify the source and intent of spec
	specific probes, but there is no authentication possible for the inline informat		ific probes, but there is no authentication possible for the inline information.
	ion. Therefore, a malevolent actor could provide false information while conduc		Therefore, a malevolent actor could provide false information while conducting
	ting the probes, or spoof them, so that the action is attributed to a third part		the probes or spoof them so that the action is attributed to a third party. In
	y. In that case, not only would this third party be wrongly accused, but it migh		that case, not only would this third party be wrongly accused, but it might also
	t also be exposed to unwanted solicitations (e.g., angry emails or phone calls,		be exposed to unwanted solicitations (e.g., angry emails or phone calls if the
	if the malevolent actor used someone else's email address or phone number). As a		malevolent actor used someone else's email address or phone number). As a conseq
	consequence, the recipient of this information cannot trust it without confirma		uence, the recipient of this information cannot trust it without confirmation.
	tion. If a recipient cannot confirm the information or does not wish to do so,		If a recipient cannot confirm the information or does not wish to do so, it shou
	it should treat the flows as if there were no probe attribution. Note that using		ld treat the flows as if there were no probe attribution. Note that using probe
	the probe attribution do not create a new DDoS vector since there is no expecta		attribution does not create a new DDoS vector since there is no expectation that
	tion that third parties would automatically confirm the information obtained.</t		third parties would automatically confirm the information obtained.</t>
	>		<t>As the Probe Description URI is transmitted in the clear and as the Pro
	<t>As the Probe Description URI is transmitted in the clear and as the Pro		be Description File is publicly readable, Personally Identifiable Information (P
	be Description File is publicly readable, Personally Identifiable Information (P		II) should not be used for an email address and a phone number; a generic or gro
	II) should not be used for email address and phone number; a generic or group em		up email address and phone number should be preferred. Also, the Probe Descripti
	ail address and phone number should be preferred. Also, the Probe Description Fi		on File could contain malicious data (e.g., links) and therefore should not be b
	le could contain malicious data (e.g., links) and therefore should not be blindl		lindly trusted.</t>
	y trusted.</t>
	</section>		</section>
	<section anchor="iana">		<section anchor="iana">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>The "Well-Known URIs" registry should be updated with the following add		<t>IANA has added the following URI suffix to the "Well-Known URIs" regist
	itional values (using the template from <xref target="RFC8615"/>):</t>		ry in accordance with <xref target="RFC8615"/>:</t>
	<ul spacing="normal">		<dl newline="false" spacing="normal">
	<li>URI suffix: probing.txt</li>		<dt>URI Suffix:</dt> <dd>probing.txt</dd>
	<li>Change controller: IETF</li>		<dt>Change Controller:</dt> <dd>IETF</dd>
	<li>Specification document(s): this document</li>		<dt>Reference:</dt> <dd>RFC 9511</dd>
	<li>Status: permanent</li>		<dt>Status:</dt> <dd>permanent</dd>
	</ul>		</dl>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.vyncke-v6ops-james" to="JAMES"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC9116">
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9116.xml"
	<title>A File Format to Aid in Security Vulnerability Disclosure</ti		/>
	tle>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"
	<seriesInfo name="DOI" value="10.17487/RFC9116"/>		/>
	<seriesInfo name="RFC" value="9116"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"
	<author fullname="E. Foudil" initials="E." surname="Foudil"/>		/>
	<author fullname="Y. Shafranovich" initials="Y." surname="Shafranovi		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"
	ch"/>		/>
	<date month="April" year="2022"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"
	<abstract>		/>
	<t>When security vulnerabilities are discovered by researchers, pr		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"
	oper reporting channels are often lacking. As a result, vulnerabilities may be l		/>
	eft unreported. This document defines a machine-parsable format ("security.txt")		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"
	to help organizations describe their vulnerability disclosure practices to make		/>
	it easier for researchers to report vulnerabilities.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8615">
	<front>
	<title>Well-Known Uniform Resource Identifiers (URIs)</title>
	<seriesInfo name="DOI" value="10.17487/RFC8615"/>
	<seriesInfo name="RFC" value="8615"/>
	<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
	>
	<date month="May" year="2019"/>
	<abstract>
	<t>This memo defines a path prefix for "well-known locations", "/.
	well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
	<t>In doing so, it obsoletes RFC 5785 and updates the URI schemes
	defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI
	schemes that support well-known URIs in their registry.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC4443">
	<front>
	<title>Internet Control Message Protocol (ICMPv6) for the Internet P
	rotocol Version 6 (IPv6) Specification</title>
	<seriesInfo name="DOI" value="10.17487/RFC4443"/>
	<seriesInfo name="RFC" value="4443"/>
	<seriesInfo name="STD" value="89"/>
	<author fullname="A. Conta" initials="A." surname="Conta"/>
	<author fullname="S. Deering" initials="S." surname="Deering"/>
	<author fullname="M. Gupta" initials="M." role="editor" surname="Gup
	ta"/>
	<date month="March" year="2006"/>
	<abstract>
	<t>This document describes the format of a set of control messages
	used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Cont
	rol Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]</
	t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC792">
	<front>
	<title>Internet Control Message Protocol</title>
	<seriesInfo name="DOI" value="10.17487/RFC0792"/>
	<seriesInfo name="RFC" value="792"/>
	<seriesInfo name="STD" value="5"/>
	<author fullname="J. Postel" initials="J." surname="Postel"/>
	<date month="September" year="1981"/>
	</front>
	</reference>
	<reference anchor="RFC768">
	<front>
	<title>User Datagram Protocol</title>
	<seriesInfo name="DOI" value="10.17487/RFC0768"/>
	<seriesInfo name="RFC" value="768"/>
	<seriesInfo name="STD" value="6"/>
	<author fullname="J. Postel" initials="J." surname="Postel"/>
	<date month="August" year="1980"/>
	</front>
	</reference>
	<reference anchor="RFC9293">
	<front>
	<title>Transmission Control Protocol (TCP)</title>
	<seriesInfo name="DOI" value="10.17487/RFC9293"/>
	<seriesInfo name="RFC" value="9293"/>
	<seriesInfo name="STD" value="7"/>
	<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy
	"/>
	<date month="August" year="2022"/>
	<abstract>
	<t>This document specifies the Transmission Control Protocol (TCP)
	. TCP is an important transport-layer protocol in the Internet protocol stack, a
	nd it has continuously evolved over decades of use and growth of the Internet. O
	ver this time, a number of changes have been made to TCP as it was specified in
	RFC 793, though these have only been documented in a piecemeal fashion. This doc
	ument collects and brings those changes together with the protocol specification
	from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
	6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 11
	22, and it should be considered as a replacement for the portions of those docum
	ents dealing with TCP requirements. It also updates RFC 5961 by adding a small c
	larification in reset handling while in the SYN-RECEIVED state. The TCP header c
	ontrol bits from RFC 793 have also been updated based on RFC 3168.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8200">
	<front>
	<title>Internet Protocol, Version 6 (IPv6) Specification</title>
	<seriesInfo name="DOI" value="10.17487/RFC8200"/>
	<seriesInfo name="RFC" value="8200"/>
	<seriesInfo name="STD" value="86"/>
	<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 (IPv
	6). It obsoletes RFC 2460.</t>
	</abstract>
	</front>
	</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="LARGE_SCALE" target="https://dl.acm.org/doi/pdf/10.11 45/1071690.1064256">		<reference anchor="LARGE_SCALE" target="https://dl.acm.org/doi/pdf/10.11 45/1071690.1064256">
	<front>		<front>
	<title>Efficient Algorithms for Large-Scale Topology Discovery</titl e>		<title>Efficient Algorithms for Large-Scale Topology Discovery</titl e>
	<seriesInfo name="DOI" value="10.1145/1071690.1064256"/>		<seriesInfo name="DOI" value="10.1145/1071690.1064256"/>
	<author initials="B." surname="Donnet" fullname="Benoît Donnet">		<author initials="B." surname="Donnet" fullname="Benoît Donnet">
	<organization>Université Pierre &amp; Marie Curie Laboratoire LiP6 –CNRS</organization>		<organization>Université Pierre &amp; Marie Curie Laboratoire LiP6 -CNRS</organization>
	</author>		</author>
	<author initials="P." surname="Raoult" fullname="Philippe Raoult">		<author initials="P." surname="Raoult" fullname="Philippe Raoult">
	<organization>Université Pierre &amp; Marie Curie Laboratoire LiP6 –CNRS</organization>		<organization>Université Pierre &amp; Marie Curie Laboratoire LiP6 -CNRS</organization>
	</author>		</author>
	<author initials="T." surname="Friedman" fullname="Timur Friedman">		<author initials="T." surname="Friedman" fullname="Timur Friedman">
	<organization>Université Pierre &amp; Marie Curie Laboratoire LiP6 –CNRS</organization>		<organization>Université Pierre &amp; Marie Curie Laboratoire LiP6 -CNRS</organization>
	</author>		</author>
	<author initials="M." surname="Crovella" fullname="Mark Crovella">		<author initials="M." surname="Crovella" fullname="Mark Crovella">
	<organization>Boston University Computer Science Department</organ ization>		<organization>Boston University Computer Science Department</organ ization>
	</author>		</author>
	<date year="2005"/>		<date year="2005" month="June"/>
	</front>		</front>
			<seriesInfo name="DOI" value="10.1145/1071690.1064256"/>
	</reference>		</reference>
	<reference anchor="IPV6_TOPOLOGY" target="http://www.cmand.org/papers/be holder-imc18.pdf">		<reference anchor="IPV6_TOPOLOGY" target="http://www.cmand.org/papers/be holder-imc18.pdf">
	<front>		<front>
	<title>In the IP of the Beholder Strategies for Active IPv6 Topology		<title>In the IP of the Beholder: Strategies for Active IPv6 Topolog
	Discovery</title>		y Discovery</title>
	<seriesInfo name="DOI" value="10.1145/3278532.3278559"/>
	<author initials="R." surname="Beverly" fullname="Robert Beverly">		<author initials="R." surname="Beverly" fullname="Robert Beverly">
	<organization>Naval Postgraduate School</organization>		<organization>Naval Postgraduate School</organization>
	</author>		</author>
	<author initials="R." surname="Durairajan" fullname="Ramakrishnan Du rairajan">		<author initials="R." surname="Durairajan" fullname="Ramakrishnan Du rairajan">
	<organization>University of Oregon</organization>		<organization>University of Oregon</organization>
	</author>		</author>
	<author initials="D." surname="Plonka" fullname="David Plonka">		<author initials="D." surname="Plonka" fullname="David Plonka">
	<organization>Akamai Technologies</organization>		<organization>Akamai Technologies</organization>
	</author>		</author>
	<author initials="J. P." surname="Rohrer" fullname="Justin P. Rohrer ">		<author initials="J." surname="Rohrer" fullname="Justin P. Rohrer">
	<organization>Naval Postgraduate School</organization>		<organization>Naval Postgraduate School</organization>
	</author>		</author>
	<date year="2018"/>		<date year="2018" month="October"/>
	</front>		</front>
			<seriesInfo name="DOI" value="10.1145/3278532.3278559"/>
	</reference>		</reference>
	<reference anchor="IPV4_TOPOLOGY" target="http://www.cmand.org/papers/ya rrp-imc16.pdf">		<reference anchor="IPV4_TOPOLOGY" target="http://www.cmand.org/papers/ya rrp-imc16.pdf">
	<front>		<front>
	<title>Yarrp'ing the Internet Randomized High-Speed Active Topology		<title>Yarrp'ing the Internet: Randomized High-Speed Active Topology
	Discovery</title>		Discovery</title>
	<seriesInfo name="DOI" value="10.1145/2987443.2987479"/>
	<author initials="R." surname="Beverly" fullname="Robert Beverly">		<author initials="R." surname="Beverly" fullname="Robert Beverly">
	<organization>Naval Postgraduate School</organization>		<organization>Naval Postgraduate School</organization>
	</author>		</author>
	<date year="2016"/>		<date year="2016" month="November"/>
	</front>		</front>
			<seriesInfo name="DOI" value="10.1145/2987443.2987479"/>
	</reference>		</reference>
	<reference anchor="RIPE_ATLAS" target="https://atlas.ripe.net/">		<reference anchor="RIPE_ATLAS" target="https://atlas.ripe.net/">
	<front>		<front>
	<title>RIPE Atlas</title>		<title>RIPE Atlas</title>
	<author>		<author>
	<organization/>		<organization>RIPE Network Coordination Centre (RIPE NCC)</organiz ation>
	</author>		</author>
	<date>n.d.</date>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="NCSC" target="https://www.ncsc.gov.uk/">		<reference anchor="NCSC" target="https://www.ncsc.gov.uk/">
	<front>		<front>
	<title>The National Cyber Security Centre</title>		<title>The National Cyber Security Centre</title>
	<author>		<author>
	<organization/>		<organization>UK NCSC</organization>
	</author>		</author>
	<date>n.d.</date>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="NCSC_SCAN_INFO" target="https://www.ncsc.gov.uk/infor mation/ncsc-scanning-information">		<reference anchor="NCSC_SCAN_INFO" target="https://www.ncsc.gov.uk/infor mation/ncsc-scanning-information">
	<front>		<front>
	<title>NCSC Scanning information</title>		<title>NCSC Scanning information</title>
	<author>		<author>
	<organization/>		<organization>UK NCSC</organization>
	</author>		</author>
	<date>n.d.</date>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="SCAPY" target="https://scapy.net/">		<reference anchor="SCAPY" target="https://scapy.net/">
	<front>		<front>
	<title>Scapy</title>		<title>Scapy</title>
	<author>		<author>
	<organization/>		<organization/>
	</author>		</author>
	<date>n.d.</date>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="ANRW_PAPER" target="https://pure.mpg.de/rest/items/it em_3517635/component/file_3517636/content">		<reference anchor="ANRW_PAPER" target="https://pure.mpg.de/rest/items/it em_3517635/component/file_3517636/content">
	<front>		<front>
	<title>Crisis, Ethics, Reliability &amp; a measurement.network - Ref lections on Active Network Measurements in Academia</title>		<title>Crisis, Ethics, Reliability &amp; a measurement.network - Ref lections on Active Network Measurements in Academia</title>
	<seriesInfo name="DOI" value="10.1145/3606464.3606483"/>
	<author initials="T." surname="Fiebig" fullname="Tobias Fiebig">		<author initials="T." surname="Fiebig" fullname="Tobias Fiebig">
	<organization>Max-Planck-Institut für Informatik</organization>		<organization>Max-Planck-Institut für Informatik</organization>
	</author>		</author>
	<date year="2023"/>		<date year="2023" month="July"/>
	</front>
	</reference>
	<reference anchor="RFC7872">
	<front>
	<title>Observations on the Dropping of Packets with IPv6 Extension H
	eaders in the Real World</title>
	<seriesInfo name="DOI" value="10.17487/RFC7872"/>
	<seriesInfo name="RFC" value="7872"/>
	<author fullname="F. Gont" initials="F." surname="Gont"/>
	<author fullname="J. Linkova" initials="J." surname="Linkova"/>
	<author fullname="T. Chown" initials="T." surname="Chown"/>
	<author fullname="W. Liu" initials="W." surname="Liu"/>
	<date month="June" year="2016"/>
	<abstract>
	<t>This document presents real-world data regarding the extent to
	which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as
	originally measured in August 2014 and later in June 2015, with similar results)
	and where in the network such dropping occurs. The aforementioned results serve
	as a problem statement that is expected to trigger operational advice on the fi
	ltering of IPv6 packets carrying IPv6 EHs so that the situation improves over ti
	me. This document also explains how the results were obtained, such that the cor
	responding measurements can be reproduced by other members of the community and
	repeated over time to observe changes in the handling of packets with IPv6 EHs.<
	/t>
	</abstract>
	</front>		</front>
			<seriesInfo name="DOI" value="10.1145/3606464.3606483"/>
	</reference>		</reference>
	<reference anchor="I-D.draft-vyncke-v6ops-james">
	<front>
	<title>Just Another Measurement of Extension header Survivability (J
	AMES)</title>
	<seriesInfo name="Internet-Draft" value="draft-vyncke-v6ops-james-03
	"/>
	<author fullname="Éric Vyncke" initials="E." surname="Vyncke">
	<organization>Cisco</organization>
	</author>
	<author fullname="Raphaël Léas" initials="R." surname="Léas">
	<organization>Université de Liège</organization>
	</author>
	<author fullname="Justin Iurman" initials="J." surname="Iurman">
	<organization>Université de Liège</organization>
	</author>
	<date day="9" month="January" year="2023"/>
	<abstract>
	<t> In 2016, RFC7872 has measured the drop of packets with IPv6
	extension
	headers. This document presents a slightly different methodology
	with more recent results. It is still work in progress.
	</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7872.xml"
	</abstract>		/>
	</front>
	</reference>		<reference anchor="I-D.vyncke-v6ops-james" target="https://datatracker.ietf.org/
	<reference anchor="RFC4942">		doc/html/draft-vyncke-v6ops-james-03">
	<front>		<front>
	<title>IPv6 Transition/Co-existence Security Considerations</title>		<title>
	<seriesInfo name="DOI" value="10.17487/RFC4942"/>		Just Another Measurement of Extension header Survivability (JAMES)
	<seriesInfo name="RFC" value="4942"/>		</title>
	<author fullname="E. Davies" initials="E." surname="Davies"/>		<author initials="É." surname="Vyncke" fullname="Éric Vyncke">
	<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>		</author>
	<author fullname="P. Savola" initials="P." surname="Savola"/>		<author initials="R." surname="Léas" fullname="Raphaël Léas">
	<date month="September" year="2007"/>		<organization>Université de Liège</organization>
	<abstract>		</author>
	<t>The transition from a pure IPv4 network to a network where IPv4		<author initials="J." surname="Iurman" fullname="Justin Iurman">
	and IPv6 coexist brings a number of extra security considerations that need to		<organization>Université de Liège</organization>
	be taken into account when deploying IPv6 and operating the dual-protocol networ		</author>
	k and the associated transition mechanisms. This document attempts to give an ov		<date month="January" day="9" year="2023"/>
	erview of the various issues grouped into three categories:</t>		</front>
	<t>o issues due to the IPv6 protocol itself, o issues due to trans		<seriesInfo name="Internet-Draft" value="draft-vyncke-v6ops-james-03"/>
	ition mechanisms, and o issues due to IPv6 deployment.</t>		</reference>
	<t>This memo provides information for the Internet community.</t>
	</abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4942.xml"
	</front>		/>
	</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="acknowledgments">
	<name>Acknowledgments</name>
	<t>The authors would like to thank Alain Fiocco, Fernando Gont, Ted Hardie
	, Mehdi Kouhen, and Mark Townsley for helpful discussions as well as Raphael Lea
	s for an early implementation.</t>
	<t>The authors would also like to gracefully acknowledge useful reviews an
	d comments received from Warren Kumari, Jen Linkova, Mark Nottingham, Prapanch R
	amamoorthy, Tirumal Reddy, Andrew Shaw, and Magnus Westerlund.</t>
	</section>
	<section anchor="examples">		<section anchor="examples">
	<name>Examples of in-band Attribution</name>		<name>Examples of In-Band Attribution</name>
	<t>Here are several examples generated by <xref target="SCAPY"/> and displ ayed in the 'tcpdump' format:</t>		<t>Here are several examples generated by <xref target="SCAPY"/> and displ ayed in the 'tcpdump' format:</t>
	<ul spacing="normal">		<t>IP packet with Probe Description URI inside a Destination Options exten
	<li>IP packet with Probe Description URI inside a Destination Options ex		sion header:</t>
	tension header</li>
	<li>IP packet with the URI in the data payload of a TCP SYN</li>
	<li>IP echo request with another URI in the data part of the ICMP ECHO_R
	EQUEST</li>
	<li>IPv4 echo request with a URI in the data part if the ICMP ECHO_REQUE
	ST</li>
	</ul>
	<artwork><![CDATA[		<artwork><![CDATA[
	IP6 2001:db8:dead::1 > 2001:db8:beef::1: DSTOPT 60878 > traceroute:		IP6 2001:db8:dead::1 > 2001:db8:beef::1: DSTOPT 60878 > traceroute:
	Flags [S], seq 0, win 8192, length 0		Flags [S], seq 0, win 8192, length 0
	0x0000: 6000 0000 0044 3c40 2001 0db8 dead 0000 `....D<@........		0x0000: 6000 0000 0044 3c40 2001 0db8 dead 0000 `....D<@........
	0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................		0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................
	0x0020: 0000 0000 0000 0001 0605 012c 6874 7470 ...........,http		0x0020: 0000 0000 0000 0001 0605 012c 6874 7470 ...........,http
	0x0030: 733a 2f2f 6578 616d 706c 652e 6e65 742f s://example.net/		0x0030: 733a 2f2f 6578 616d 706c 652e 6e65 742f s://example.net/
	0x0040: 2e77 656c 6c2d 6b6e 6f77 6e2f 7072 6f62 .well-known/prob		0x0040: 2e77 656c 6c2d 6b6e 6f77 6e2f 7072 6f62 .well-known/prob
	0x0050: 696e 672e 7478 7400 edce 829a 0000 0000 ing.txt.........		0x0050: 696e 672e 7478 7400 edce 829a 0000 0000 ing.txt.........
	0x0060: 0000 0000 5002 2000 2668 0000 ....P...&h..		0x0060: 0000 0000 5002 2000 2668 0000 ....P...&h..
			]]></artwork>
			<t>IP packet with the URI in the data payload of a TCP SYN:</t>
			<artwork><![CDATA[
	IP6 2001:db8:dead::1.15581 > 2001:db8:beef::1.traceroute:		IP6 2001:db8:dead::1.15581 > 2001:db8:beef::1.traceroute:
	Flags [S], seq 0:23, win 8192, length 23		Flags [S], seq 0:23, win 8192, length 23
	0x0000: 6000 0000 002b 0640 2001 0db8 dead 0000 `....+.@........		0x0000: 6000 0000 002b 0640 2001 0db8 dead 0000 `....+.@........
	0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................		0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................
	0x0020: 0000 0000 0000 0001 3cdd 829a 0000 0000 ........<.......		0x0020: 0000 0000 0000 0001 3cdd 829a 0000 0000 ........<.......
	0x0030: 0000 0000 5002 2000 c9b7 0000 6d61 696c ....P.......mail		0x0030: 0000 0000 5002 2000 c9b7 0000 6d61 696c ....P.......mail
	0x0040: 746f 3a6c 6162 4065 7861 6d70 6c65 2e6e to:lab@example.n		0x0040: 746f 3a6c 6162 4065 7861 6d70 6c65 2e6e to:lab@example.n
	0x0050: 6574 00 et.		0x0050: 6574 00 et.
			]]></artwork>
			<t>IP echo request with another URI in the data part of the ICMP E
			CHO_REQUEST:</t>
			<artwork><![CDATA[
	IP6 2001:db8:dead::1 > 2001:db8:beef::1: ICMP6, echo request, id 0,		IP6 2001:db8:dead::1 > 2001:db8:beef::1: ICMP6, echo request, id 0,
	seq 0, length 28		seq 0, length 28
	0x0000: 6000 0000 001c 3a40 2001 0db8 dead 0000 `.....:@........		0x0000: 6000 0000 001c 3a40 2001 0db8 dead 0000 `.....:@........
	0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................		0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................
	0x0020: 0000 0000 0000 0001 8000 2996 0000 0000 ..........).....		0x0020: 0000 0000 0000 0001 8000 2996 0000 0000 ..........).....
	0x0030: 7465 6c3a 2b31 2d32 3031 2d35 3535 2d30 tel:+1-201-555-0		0x0030: 7465 6c3a 2b31 2d32 3031 2d35 3535 2d30 tel:+1-201-555-0
	0x0040: 3132 3300 123.		0x0040: 3132 3300 123.
			]]></artwork>
			<t>IPv4 echo request with a URI in the data part of the ICMP ECHO_
			REQUEST:</t>
			<artwork><![CDATA[
	IP 192.0.2.1 > 198.51.10.1: ICMP echo request, id 0, seq 0, length 31		IP 192.0.2.1 > 198.51.10.1: ICMP echo request, id 0, seq 0, length 31
	0x0000: 4500 0033 0001 0000 4001 8e93 c000 0201 E..3....@.......		0x0000: 4500 0033 0001 0000 4001 8e93 c000 0201 E..3....@.......
	0x0010: c633 0a01 0800 ea74 0000 0000 6d61 696c .3d....t....mail		0x0010: c633 0a01 0800 ea74 0000 0000 6d61 696c .3d....t....mail
	0x0020: 746f 3a6c 6162 4065 7861 6d70 6c65 2e6e to:lab@example.n		0x0020: 746f 3a6c 6162 4065 7861 6d70 6c65 2e6e to:lab@example.n
	0x0030: 6574 00 et.		0x0030: 6574 00 et.
	]]></artwork>		]]></artwork>
	</section>		</section>
			<section anchor="acknowledgments" numbered="false">
			<name>Acknowledgments</name>
			<t>The authors would like to thank <contact fullname="Alain Fiocco"/>, <co
			ntact fullname="Fernando Gont"/>, <contact fullname="Ted Hardie"/>, <contact ful
			lname="Mehdi Kouhen"/>, and <contact fullname="Mark Townsley"/> for helpful disc
			ussions as well as <contact fullname="Raphael Leas"/> for an early implementatio
			n.</t>
			<t>The authors would also like to gracefully acknowledge useful reviews an
			d comments received from <contact fullname="Warren Kumari"/>, <contact fullname=
			"Jen Linkova"/>, <contact fullname="Mark Nottingham"/>, <contact fullname="Prapa
			nch Ramamoorthy"/>, <contact fullname="Tirumaleswar Reddy.K"/>, <contact fullnam
			e="Andrew Shaw"/>, and <contact fullname="Magnus Westerlund"/>.</t>
			</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAJB/vWQAA81b224jyZF951fkqgFPCyZLvEviGOvRSOoZebrVWkntwcA2
	epNVSTKtYmVNXcSmhTb8us/7tH+wxgL7BfvWf+Iv2RORWTeKVGt8WayAbknF
	ysjIuJ6ISHU6nVams1BNxN5JliV6mmfaRMLMxEWUqSRSmbhKzFSley05nSbq
	Hi/aB6L2/l7Ll5mam2Q9ETqamVaaT5c6TfFRto5B/OL89lUrMH4kl/gtSOQs
	62iVzTomTpXfiYliR1YEWzpOJiJL8jTrd7vH3X5LJkpi77exSiS9kQoZBeKN
	jORcLVWU7bVWJrmbJyaP66/JUNwoP090thanMpZTHepMg/uZScTFlbhUGa3D
	aWeJTLGhn+WJ2mvdqTWeB5NSDJ0zYrp1r6JcTVpC/N12EsKKaO97fKqjufiG
	KNPzpdQhnrOIviJpeSaZ0wcy8Rf4YJFlcTo5OKD36JG+V17x2gE9OJgmZpWq
	A6ZwQCvnOlvkU6xV9+vIv3MfPZY/vRtCpWlW28et8SwRT5tdqw8+r2BvkS3D
	vVYrzaDG9zI0EUSwVmkrXcoke/9jbrD5RESmFeuJ+E1m/LZITZIlapbip/WS
	fvhdqyXzbGESKKQDjgWMD4vOPfFr5pQfWZP79G+J9uuPISMZ6T+w6ibiVKe+
	4efQjFI49ZkS34X4KZQyEuMT/sw3AUj1jgY9+ytUjRe1ggW6z/MoIx/4WoVz
	nduHyqrRCe8rn3byfLNssPy1J85MBDOrsfy1isyn/87qHzSZfhdB40mqs09/
	FoESr/Wn/5yrzzIyBVmdeQFT/SoPiX1vqhrs/MoTF3mylFGNnV/BF3VUf/73
	4Ob3TNXTTLXGTSsyeJKB5KTVopBS/ibE65Prb87f35yevD6fMC0Xwc5nM+1r
	xAJxEiIWwUqX1vtey2SuOje+DJW4NbEJzXwNvUER4HhtSdArUHth60HoSX/J
	nhQYfRAHs4Ne1+v1hiN8P+yNj/FLdzzsj8a8PICvTARC1cgakUrg+cS2ZVCI
	s7cXsJwnKJSGzF8d9/0JW3AaaAr+SqskUeJnCIzgQJzm9P9rOTWIUUYnpJar
	8V/+9O+nl9c3O7a6WiBwxbES19Lk4T92r1u9zBPxCguDwqj+UVth5Z04TaDx
	MJTNnb42aYacV26I+G2WcY64L27InnyFaBAjLFGewdKLq1+P39++vXr7+u03
	PzQs8CIS2UJRtEcCpZ++VgsTBkQoSyhDFvngxCdjxov34+dYJAxytVp5PoQU
	sE3GEmknPZg68h299HtHHqy0YY29o+dY46B/eDQa9D3+Pjp+hjVeI5gnGQ4H
	ZsN1U5iX8h6Z8AoinScyyMEJhLgwJtxFSy7lXaLTRYQ4e5YnUify9zttYU2C
	fZsAakQ76J3Jex2IKySUuw01n9xhKy1ulb+ISOCQyQ4aLtRdeTjpIlHJ808I
	0xhuN40fZJLEf/nTf1CGZxsp4NU1dGqW+g8qEN/q+aJzEyv86Azkb7CNNW3I
	hjF+bBjj5xhG//jocDgcePz98B9pGNcXV+fvT25fn9w0ZEaPATNDmW6N0ZI+
	8RIdKw+CPMA7l6c3pw0Kt5D0ZQHPTtdT8sQSpMGbE7WVMgk08lPfm5t7L78r
	SFPOuXx/cfnqbWMT+ghnkVFEyi2TlTPRz9GuvX9Azzupo9RpUsLeV02Twpbx
	9uyV0ieFUE4ur79/f3VydX7dWH0Kp9PAUufZQvv4fq1CbUHrGoFWiqWSKQAq
	xTyixNi1g7dmofItAEfMdGZaYNs31ZoUgsDHMlBLLbcyGeNNbxnPvUAdJECa
	BzpTy5T/fz8Y9Q7Hg9EBcFIMaBhlBzMdKvd4jMfwnihr2HR/8KxgN0bOHQ89
	/n40eIZN35qplql4pdVUz5sm/UZ+6FyFEriucxEhZGR5Jmaf/ichjG81d9dq
	dTodIaeAldLPWi0nsGVdUOTXHBPifBoCpZahAYbgpCYU0Aze8g2yF6c9MjXK
	SZRRkFAiE3WaH0JsqSduzFJleomXsD5tbtwWMkwNdglDRByG6PQM6fReqxUe
	4dh5tFIhtKBoEzmfQ1Ep1Rmt1u1CpwIlXU60RJrP59BhCpCOd1O9jIG1Mgq1
	+sfcJT2JD/ME2TQzQgdYpWdrobGm3DoMzYp4l9GaD7emXeswk5bmETIe1w1i
	tZAZXsaj1EByMB13DqwG2M4EGTi/xNvkSWwgA3pIq5cGRwWnKCtklIVrvGlo
	A7IuKMvj6FGeQSRwEMVWb2azTqgjBSoyXMOLinTPe7fpR5QnTD2DiLAoMhnW
	/5gTVqHD+QsZzRW5CC2DCUs6KW2cmFDEsCkFCJ6JBVQwVSoCok71PMLxkMIi
	sEryDOUaqX/Q0CkUwxa31EEQAka/IGtKTJCzz7Zab2j32gJwlSqqFcHky4eH
	GrT++LEtHh5+ef3q9PDosE+/kczw5KJz5tkCz5Y0nfsxirzO7+Et6ceP+2xA
	MEP4QqqigNQJPGT1gT3S0iBXMGmhPsCRqU8gFkqSXkV5sGHxaH+3hxBLcN5U
	lRuQz0D/kBe8APKCPv9q38n9RUmXTtXwFKu8mg9A9DfuwI/sEX6xAJoOhJne
	a5On0CAxaciGcApB4FDA+AVwfj5fENdkMjD1HK/CRmGPLADDR3HMf0HaY5cC
	t19D4Mi7kSVItIhouxCP5cJnJlCFw1sT8hwZymSJd7BopcOQjRSis26so3sS
	49w1XKbrQpSsCvbPRPlK3xegxvreS+0pj/xORbWnViPWi2UQUCAR5DkkAver
	TJ2R4/i0sCLOm+2TssCEJLkngeNgIfkNZjhQ99rnWJewGFdIbYumBEiPiMWw
	Odb0S+XNPTLtyqbcpwIk8GTfhoGGKKyoCgWW0QCs5anlloMPkjC1eNJ6QKjk
	UWuG/NUxIv3/EYdRoneeFYvL9zbCMT1/RkRm7md5wjZYQ0eQwgXRRzSJAU7I
	gGgTQ4GyjG+JizhzYwIsJvzAVs26zFPlEmQlK5IDTIfsCHIgTS+Bz7Pi3SUZ
	hmYbDgDO8zRVRBcRMnUI8+NHMPY9ymmr9iqTWC+EZPLUGvuSitMGJihDAzTA
	4bCWYjKDaCUgef+uTRkGHLisUGYJ0GRARgLbStfSHIiXJHbSBnzP+FqS8Ezs
	8F3yODzve5RTuAOMojj1gb5tYmFZpBYaEpOowsjbxEquHxldwAurSFGzw/2a
	IdJWW/YS764vxMMLiPjjpvUHagZHpG23r5L0Ef0QG1gAR60iPbANb1v3ivT3
	MlUKmiUQyikudVs5jWsAAcqQNphUDdMPkvyPgbgHHBV27iKzig7oeNjcyz5k
	e19a27f9sCISlpToYWYmSE1f1Yi5RSJekDajfIm6plySqXDy814HRV5nNBp1
	ur3+YG+XJPlsDy/4WMCmO05FZrdj7RKVMhnyEsYhUOBpcBqyge3tPLENqE8R
	nBkKQLyv9fE6X4WNDckjHh7+CQDluNcbf/zIEcSlWQ4YLnJaaqTsmVZhkG4j
	1t8kxuZwKgENNLI+/WxDEH46/xAjRKf46QpBnRpTQec1QnUuEXkhRRGpld1K
	7NXOt1fwxqB7SoHdD/PAOmvpEcRwvfJC+QHhZpzFfpI02hacWD4KNUlKtzZZ
	oSAhkXBIjIywCSxR8o5t5QVOyebWav3xj3+Ex5eiYPd5qWcUmfZb5eOqrKsb
	ff0kUD2FDifHwtJb7veJ2G7qtOTXMtQB4mnLSd5We51evzPo3faOJoPDSffw
	D/RmpYYtqpkAXMFL4FyzpAxiqRO9jWI1dU3K6P5YaLUlDeSPiEXSAu23edYx
	s86UTNJaem1aRjaCzJdqV21TeHyMCbAzDGOaazIZkSKx6RmgL4l/KilvGGve
	LqwWGKrOj8u87ZoLWBM5GvdGyE7iFYd4FnbbmoJ0Kzeo9rvd3iSYHk0CpIHJ
	pNfe8CziCgwTtxm7jp45BEd9O/j55Q2hOQPURqfdJAcmdJpVYa8e63iraEcQ
	cvv+pIjL8Qc4w7kjKDJQoFD6mN0vLeJe6VQ9GQjrvs2HsUmPEfUmTTu6pAjA
	SQ/ew/FchXjrpSFkQ3LXRHx/16abB//tbzZl+tvf7ZYA5U1ltcWUqvjAbsMt
	b4fBn5UQPU4elMUKY6Kl7777TO8NBKh3htANIESOBrxKo8y6H7C21oKaYizS
	+zyMVFJNV6WfGKokijGtTxMSxoDpOqWGUgGgwQ2JnSvIdFGHj86TdCKK1huV
	ws2GHw7ZdrCmKHY2PG6lprG0eL2mcs+W4LsjQeQqumfGA5c0diIcXS+5AKVU
	OPPEt2TuHMmo1FUfFpIa3PeoOMlQwb9TW8quS0GB6qHTNzSdAGg1ZVVoo8dw
	OBxQgil4IQhaK1I45Xy5SWm4jdLhcf/5hMS7syv+YJ7IZUFgfPQEgViuQyMD
	F4ysDJDr8jhWScci4BJOy1nmCluu/6gEsSC5xsDt6RUS7pyhpsu1/eOnRPF3
	ZiCyAyNXT7lQDr9/zAHMQwaXDskXVbsGkmfT+dbEnem6g2+E8c9qhflbB/0t
	2ndxYrulccxAEQI2pe1NzHRC5gTny8o05ATAxZ0LMjjmkvaDi1IxH1Uruh+6
	XZyEawKco1gQ5Qij1SpPXMyeiIrkwobXoUT2qYtpuZuqubbO3eTN5ZfafjH1
	HYLt7GHzKFVJVgSBHTxs9nqog7wB7Zx3FpmyUSpPFbVcU+g/mbNRSOfWEin6
	ze0729ct3ZabGnNNzR9nfRIWFgX6A4ykeImr0UtDzXLbpZCAXHMgCgdqXC0m
	UcBzkcqIA5HbxJJ+pRJVJfsUg6jGxAeWa9TMlC3MUyrRRXMDp8LRA9ta5g5F
	0WyJTFC2p8B8SF2eQM84GWUkHJ8az4ThKTgWvT6L8q0uuAquzoPDks+4NhKy
	rs1J2oXix/F1Rd3usob/TJeTw3r96g/R5MkiY2SAWnI1d1Op1XrHrNeaZ6aG
	Dznj2x/LFkGbi29S6BT5AQddTgnxt8VCzxdc6JN+uRltWxlFawgFu+tLFJVB
	UVpYA8zj1Bbm2C0ALrC/UQqQVGNU+6fGNlGsoPCm683a35fyjn7npJwoxRz5
	FFy4u0OtB+pbOxRkc6sP0Jq6iCKDewnVze3W1hw3xVK1S7hlt3Bu7HBM05Os
	fdk2qfXb7X02fLMQLbNNKO4ZyXTNVg2/y+Mi/IBEkttwISm101yJmtDUvCwb
	mtRsfKp6Sz3xjmBGllPgCteuEcgHsv1KndZEkRlD4cV+xOJqf1Y2tiVVBDwG
	EUBnQa7skcAyzBGGYeEkaqBNr5Xi8uSWWjBUZ0Zr1EgBN0cYbUAEm8dv10Tr
	ioSLqxILVcGXUWfRXq0GuXCtatgL4FfryqakylliljWCri1K5rehVrZIYLJg
	HckleX2jYCHRqcx35hYnGuFrXZld0+oeeR9jLWchPHW3vsMqoba26+Nu14gz
	xhnMgHXxUqalgQQ0GLlXrqdcsFW3gubWFA1jw61KlBLb8whdh9OkzCIqch23
	Oxhbi5my8fkyCSihNupARi6EFqm4s/GwBnxq9G9+uBSzUDJarsDQPnvZUpYN
	bAbHknW3ZkW7aE7hzDrbZ8g3wvxPOVYBrt3RrGx3JqmiHcPw6bkQqV2hqhri
	wtapiF2sr1Ua8EU7UhseDxn5lv0nr+cde6Oineu6+EUju4nmikkSFa1Fn6v7
	RVlUpkuaUjnQcGTRC48gcuAJ1FcMXajJSn3sraUGA6zmnrUBBeGCrMyrnM/5
	bDt45765ZE45JYogMXHME5vaeG3DBIn6ax3lH8R3VNWFrtNQDLGbG7tkZtWe
	Nsg6z6DT8v0hnGTgjQCov7VDI06um67MHfHNkJCWOdgmkAW3kqd6XgWVGnJt
	Nvgll8YaMTgh0cF3I857e3TxwHYASCl7TxrnY/TSZhXfcaCW2DJJVFiMp7Yc
	q4pQxcyr0ZoIjbnLY0SmamCxIxvTXV1SdEgBH5xENtfExsxwCqs8K6wNbh7H
	WUMAjwTJgx+67BGqjPJKmLu5zgt7P2ULpjr/oPw824QCNAFK+M5e7V7FPDRT
	UCgnfBUwd/M2oAC3i1/fpe0GiI9HPNWdGm77O6zMAyvVHIEVABfmXZ+AFuNn
	ioc6ujfhPQLW5jgDwqUJWcrqXS4ZpK4bU7t6A5BH4aocq1Fut5dNCsgEzoGD
	SSZUhwe578aRRYJB4MbHRTukOciz7IJDGjNXKMa4yXpdNdy2BGlAREansE6f
	rwBPbHav14XuIk9hki5AQ32G2yz31Pn95X7Ri2JZur8rsCNzbkOxQz48NK5l
	unEAPx3Wn1LEY4BVSCXl+3YWO6acmUl6G0fis+ZcBaa+iV290xz+v6i1t5qr
	H16UI8GdKt4+qt0Wm3dNOgsTbkw8ORAVE8vCnu1T3pGMiARVswe6ndEwsgKj
	2U5bVru8yHB1BsG1H01PN2Igl9I0RG0jG5BVwf/s3Yus4MrGxRLoNxp0U8py
	IFPhy2mIgIpT89+IULJ/V+C5JhsuW9Iq2qBIqFaw7rJISYNucSlqCcBhq/Zw
	YQsulJfhyRU3xVUEzRC+gddqV5U4oCZ6TugiCopajQ2KE5adH7jSrdjAYUmE
	tBllDgJWOts2XX1kJ7XQNVVZVuCByFTESQ5hWELkLf1Gt1HwVMgpys9ZNaIo
	rhFMy1Bh2171dEchsKhWXI0IUjxkqQ/2he3V09WJNjcsQoVYSRvC6LjkZYhs
	+YQlUgu9bjgrTmZU/9AFqPotlZRLbM5azjeKspD7J34hg0IkVgqNqyeeve8t
	M64M2rZSIU+0/sXxoX5TBQJeIV3Oqbnh+zkDYKdSi16LySCc27ibAXm0Arqg
	braNxS6ilNdW5qgfeHRsi3MeCNM1JRzPNZYeyYz9kUIgvUtDB2DHxvS5omRH
	y/sMZyX7AbVvkVzbBQDUsXbq5+PWZe98lZ2Lzkg4gGIoyMx0pWDGmhUlt8q9
	9DgSJBUWXVEfn8pvMuq6z2aJKlqSjBrhtWUHdkX/wRi3RFZqjll9VrXhtrs6
	vLlPexDsp2nv2Zm5AcJk8VrIWbd7G6vdvRlrYfWYYa0FzmHojD4Hjp3Hd4HQ
	Dlye7Li5ZJllFrMwKgsVDVcijmNPDHfI9fmiHSMkGdBMvy2uEMqohMHDCxsM
	NA/7L2r8vby6uNivx9wi/pOPN42McWzNyr6ELOcKRT0iCF7mv6/7zJJajI6L
	eS9sNSRreOJ4fuOKQJWOuPB1noVIdJfuF6DKXd5qnmszA/Gk5+Ty5HH254sU
	Ns7ufU8jue+4OQJFpXsQ8FynGdy4OkweB9weL5FzNWgtBoPI8wBHlOBeVsaa
	KWR0skrGWfVR7z5Pdsgy0nw20x8mBfyxY/mOOLW1urtdhvrR/c0mPrpxcV06
	87fI5WW6P2lCIH4XZp6nE8pYSxnxQ3sfdYqCjAR04lNjKFSBrfZdO5AvYBee
	EOo7N31EdQNtkpJeaQMM2RavADvo7yXEN2C0LW7pjyZQ9WmY5xu1CLT4zuQL
	GvPbPw5N7sQtNTlDZdPkQoXxLA8LNG+hHfaFTuj7tYwX8tN/heL1pz9Ld1cu
	EvAZewcz5BKjuHH2mHEO3wX380T6CntxsC/OzM5ADKDy0mqVOiiwtJ0Pe92R
	nIXU972EOUfiu3wpE90Wv8LPKInvzL1s25MhXFFKW0jkrqtExjJCvqc/p1ka
	k2SLNcSjE6wOxbUKAvx6EsGNVuJmIVeFgOYR7P57KteTEGDFFlzFVAFBvSjZ
	6n8b/PCiHCmgkC77ma7XWM4k2JeLKc/DA//5gkPlEH9Mo60yMH2R+XGQL+Mv
	3A0Xttby1rD1g12Fseu+bGvRbN5e20KVJ8NVgd2Y2nF3lHpTNz9cuqWNGaa9
	MOF6TI+JJOUUjAag4vz027fvr8//5d35za2ltjkTdRcwtlLSOynRjZOLq/Hj
	OxX/XD2aKjXDo4k4u0EpdCvG3aPDI7xAf5Sg+J7rpPUqlPNU/Obmd9SV+lF0
	6UJIJI56x31EQxXNwVu31aIZWLc7ESDR7Yqu/W84FAN/2OX9RBcbCuLBfir+
	1cPX2S++8twXk+gRiW6NhP2vVyNBPDsS3sYXk+jvItEdd0ei2+v7Ynx0OBSH
	w8MmiTbdmWASAyJxOBhI0Z/1Z2I8glDGvXEgDrtjrB71lRir8Qgk8KnYvF/C
	JIZEoq8OD/E6rfH7gRhPx1g4o2cKCw+7h338Ou6Di40LGUxixOI8pjWH2BH8
	HuE/nEYFABJH/WNZO6FwMbspi3FTFiNIhyQJjYzHR25h9UXLrvDvZwuP/lxg
	m/F4vdHoaJsJeU+ZzKQ/2GI1/cEOs+lPoasnzebn3v+d2Qz8IHgk7WLpL+ok
	Bruk7R9PD+2zcTDukU79Str0RWimMpvD4XgmBpLMpgfrGHbJ1I5oYQCTHfv4
	ta9gFmLzWlzNbEaw8KZ2t3+pbJeqt8YJijPjdiM8AWBDN+2WCw6Fco92KLfn
	42hPKteb/N8p94id4fh4vE25nre/oVxoZgQFUGCYDsBAMOiLQdf+NBKDEf7D
	TyCxedm2Uu6gR2sGn9dNrz+wqhFwGq/r9T1SSe/4yBvBDbue08Y2XYimLga9
	mi6GIz7nYOCCIp14yKJQxwPhsxTAthDnnjeg03/1SBf+mFZLWn1E4UiyrRXi
	q5v4IKCVWcPE+3+7iQ9+solTMvxfsfB3ctREAAA=
	</rfc>		</rfc>
End of changes. 67 change blocks.
	536 lines changed or deleted		254 lines changed or added
This html diff was produced by rfcdiff 1.48.