[要約] 公共インターネット上のアクティブな測定は、協力する当事者または非協力する当事者のどちらかを対象とすることができます。これらの測定は時々、「プローブ」とも呼ばれ、歓迎されないまたは攻撃的と見なされることがあります。この文書は、ソースが自身のプローブを識別するためのいくつかの簡単な技術を提案しています。この技術を使用することで、どの当事者や組織が問題のプローブパケットであるか、その目的は何か、そして何よりも重要なのは誰に連絡すべきかを理解することができます。この技術は、プローブのオフライン分析に依存しているため、データまたは制御プレーンの変更は必要ありません。主に第3層の測定のために設計されています。
Internet Engineering Task Force (IETF) É. Vyncke
Request for Comments: 9511 Cisco
Category: Informational B. Donnet
ISSN: 2070-1721 J. Iurman
Université de Liège
November 2023
Active measurements over the public Internet can target either collaborating parties or non-collaborating ones. Sometimes these measurements, also called "probes", are viewed as unwelcome or aggressive.
パブリックインターネットを介した積極的な測定は、協力しているパーティーまたは非協力者のいずれかをターゲットにすることができます。「プローブ」とも呼ばれるこれらの測定値は、歓迎されない、または攻撃的であると見なされることがあります。
This document suggests some simple techniques for a source to identify its probes. This allows any party or organization to understand what an unsolicited probe packet is, what its purpose is, and, most importantly, who to contact. The technique relies on offline analysis of the probe; therefore, it does not require any change in the data or control plane. It has been designed mainly for layer 3 measurements.
このドキュメントは、ソースがそのプローブを識別するためのいくつかの簡単な手法を示唆しています。これにより、あらゆる当事者や組織が、未承諾のプローブパケットとは何か、その目的が何であるか、そして最も重要なことに、誰に連絡するかを理解することができます。この手法は、プローブのオフライン分析に依存しています。したがって、データまたはコントロールプレーンの変更は必要ありません。主にレイヤー3測定用に設計されています。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9511.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9511で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Probe Description
2.1. Probe Description URI
2.2. Probe Description File
2.2.1. Example
3. Out-of-Band Probe Attribution
4. In-Band Probe Attribution
5. Operational and Technical Considerations
6. Ethical Considerations
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Examples of In-Band Attribution
Acknowledgments
Authors' Addresses
Most measurement research (e.g., [LARGE_SCALE], [RFC7872], and [JAMES]) is about sending IP packets (sometimes with extension headers or layer 4 headers) over the public Internet, and those packets can be destined to either collaborating parties or non-collaborating ones. Such packets are called "probes" in this document.
ほとんどの測定研究（例：[large_scale]、[rfc7872]、および[james]）は、パブリックインターネット上にIPパケット（拡張ヘッダーまたはレイヤー4ヘッダーを使用）を送信することであり、これらのパケットは、協力するパーティーまたは協力するパーティーのいずれかに運命づけられる可能性があります。非協力的なもの。このようなパケットは、このドキュメントで「プローブ」と呼ばれます。
Sending unsolicited probes should obviously be done at a rate low enough to not unduly impact the other parties' resources. But even at a low rate, those 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 address assigned to the receiving party) or a third party having some devices through which those probes are transiting (e.g., an Internet transit router). The investigation will be done offline by using packet captures; therefore, probe attribution does not require any change in the data or control planes.
未承諾プローブの送信は、明らかに、他の当事者のリソースに不当に影響を与えないほど十分な低速度で行う必要があります。しかし、これらのプローブは、プローブを受け取る当事者（つまり、プローブの宛先アドレスが受信者に割り当てられた1つのアドレスである場合）または一部のデバイスを介していくつかのデバイスを持っている場合の調査を要求するアラームをトリガーする可能性があります。これらのプローブが通過している（たとえば、インターネットトランジットルーター）。調査は、パケットキャプチャを使用してオフラインで行われます。したがって、プローブの帰属では、データやコントロールプレーンの変更は必要ありません。
This document suggests some simple techniques for a source to identify its probes. This allows any party or organization to understand:
このドキュメントは、ソースがそのプローブを識別するためのいくつかの簡単な手法を示唆しています。これにより、あらゆる当事者や組織が理解できます。
* what an unsolicited probe packet is,
* 未承諾のプローブパケットは何ですか、
* what its purpose is, and
* その目的は何ですか、そして
* most importantly, who to contact for further information.
* 最も重要なことは、詳細については誰に連絡するか。
It is expected that only researchers with good intentions will use these techniques, although anyone might use them. This is discussed in Section 7.
誰もがそれらを使用するかもしれませんが、善意の研究者のみがこれらの手法を使用することが期待されています。これについては、セクション7で説明します。
While the technique could be used to mark measurements done at any layer of the protocol stack, it is mainly designed to work for measurements done at layer 3 (and its associated options or extension headers).
この手法は、プロトコルスタックの任意のレイヤーで行われた測定値をマークするために使用できますが、主にレイヤー3（および関連するオプションまたは拡張ヘッダー）で行われる測定のために機能するように設計されています。
This section provides a way for a source to describe (i.e., to identify) its probes.
このセクションでは、ソースがそのプローブを説明する（つまり、識別する）方法を提供します。
This document defines a Probe Description URI as a URI pointing to one of the following:
このドキュメントでは、プローブの説明URIを次のいずれかを指すURIとして定義しています。
* a Probe Description File (see Section 2.2) as defined in Section 8, e.g., "https://example.net/.well-known/probing.txt";
* セクション8で定義されているプローブ説明ファイル（セクション2.2を参照）、例えば「https://example.net/.well-known/probing.txt」;
* an email address, e.g., "mailto:lab@example.net"; or
* たとえば、「mailto：lab@example.net」などのメールアドレス。または
* a phone number, e.g., "tel:+1-201-555-0123".
* 電話番号、例えば「Tel：1-201-555-0123」。
As defined in Section 8, 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 [RFC9116] and should contain the following fields defined in Section 2 of [RFC9116]:
セクション8で定義されているように、プローブの説明ファイルは「/.Well-Nowned/Probing.txt」で利用可能にする必要があります。プローブ説明ファイルは、[RFC9116]のセクション4で定義されている形式に従う必要があり、[RFC9116]のセクション2で定義されている次のフィールドを含める必要があります。
* Canonical
* 正規
* Contact
* 接触
* Expires
* 期限切れ
* Preferred-Languages
* 優先言語
A new field "Description" should also be included to describe the measurement. To match the format defined in Section 4 of [RFC9116], this field must be a one-line string with no line break.
測定を説明するために、新しいフィールド「説明」も含める必要があります。[RFC9116]のセクション4で定義されている形式に一致するには、このフィールドは、ラインブレークのない1行の文字列でなければなりません。
# Canonical URI (if any)
Canonical: https://example.net/measurement.txt
# Contact address
Contact: mailto:lab@example.net
# Validity
Expires: 2023-12-31T18:37:07z
# Languages
Preferred-Languages: en, es, fr
# Probes description
Description: This is a one-line string description of the probes.
A possibility for probe attribution is to build a specific URI based on the source address of the probe packet, following [RFC8615]. For example, with a probe source address 2001:db8:dead::1, the following URI is built:
プローブの帰属の可能性は、プローブパケットのソースアドレスに基づいて特定のURIを構築することです[RFC8615]。たとえば、プローブソースアドレス2001：db8：dead :: 1、次のURIが構築されます。
* If the reverse DNS record for 2001:db8:dead::1 exists, e.g., "example.net", then the Probe Description URI is "https://example.net/.well-known/probing.txt". There should be only one reverse DNS record; otherwise, the Probe Description File should also exist for all reverse DNS records and be identical.
* 2001年の逆DNSレコード：db8：dead :: 1が存在する場合、たとえば「example.net」、その後、プローブの説明は「https://example.net/.well-nown/probing.txt」です。逆DNSレコードは1つだけです。それ以外の場合、すべての逆DNSレコードに対してプローブ説明ファイルも存在し、同一である必要があります。
* Else (or in addition), the Probe Description URI is "https://[2001:db8:dead::1]/.well-known/probing.txt".
* それ以外（またはさらに）、プローブの説明uriは「https:// [2001:db8:dead:1]/.well-nking/probing.txt」です。
The built URI must be a reference to the Probe Description File (see Section 2.2).
構築されたURIは、プローブ説明ファイルへの参照である必要があります（セクション2.2を参照）。
As an example, the UK National Cyber Security Centre [NCSC] uses a similar attribution. They scan for vulnerabilities across Internet-connected systems in the UK and publish information on their scanning [NCSC_SCAN_INFO], providing the address of the web page in reverse DNS.
例として、英国国立サイバーセキュリティセンター[NCSC]は同様の帰属を使用しています。英国のインターネット接続システム全体の脆弱性をスキャンし、スキャン[ncsc_scan_info]に関する情報を公開し、逆DNSでWebページのアドレスを提供します。
Another possibility for probe attribution is to include a Probe Description URI in the probe itself. Here is a non-exhaustive list of examples:
プローブの帰属のもう1つの可能性は、プローブの説明URIをプローブ自体に含めることです。これが例の網羅的ではないリストです：
* For an ICMPv6 echo request [RFC4443], include it in the data field.
* ICMPV6エコーリクエスト[RFC4443]の場合、データフィールドに含めてください。
* For an ICMPv4 echo request [RFC0792], include it in the data field.
* ICMPV4エコー要求[RFC0792]の場合、データフィールドに含めます。
* For a UDP datagram [RFC0768], include it in the data payload if there is no upper-layer protocol after the transport layer.
* UDPデータグラム[RFC0768]の場合、輸送層の後に上層層プロトコルがない場合は、データペイロードにそれを含めます。
* For a TCP segment [RFC9293], include it in the data payload if there is no upper-layer protocol after the transport layer.
* TCPセグメント[RFC9293]の場合、輸送層の後に上層層プロトコルがない場合は、データペイロードにそれを含めます。
* For an IPv6 packet [RFC8200], include it in a PadN option inside either a Hop-by-Hop or Destination Options header.
* IPv6パケット[RFC8200]の場合は、ホップバイホップまたは宛先オプションヘッダーの内部にPADNオプションに含めます。
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 the Probe Description URI cannot be placed at the beginning of the payload, then it must be preceded by an octet of 0x00. Inserting the Probe Description URI could obviously bias the measurement itself if the probe packet becomes larger than the path MTU. Some examples are given in Appendix A.
プローブの説明URIは、ペイロードの最初のオクテットから開始する必要があり、0x00のオクテットで終了する必要があります。つまり、null終了する必要があります。プローブ説明URIをペイロードの先頭に配置できない場合、0x00のオクテットが先行する必要があります。プローブの説明を挿入するURIは、プローブパケットがPATH MTUよりも大きくなった場合、測定自体に明らかにバイアスをかける可能性があります。いくつかの例は付録Aに記載されています。
Using a magic string (i.e., a unique, special opaque marker) to signal the presence of the Probe Description URI is not recommended as some transit nodes could apply different processing for packets containing this magic string.
一部のトランジットノードは、このマジックストリングを含むパケットに異なる処理を適用できるため、魔法の文字列（つまり、ユニークな特別な不透明マーカー）を使用してプローブ説明の存在を信号することは推奨されません。
For the record, in-band probe attribution was used in [JAMES].
記録のために、帯域内プローブの帰属が[ジェームズ]で使用されました。
Using either the out-of-band or in-band technique, or even both combined, highly depends on intent or context. This section describes the upsides and downsides of each technique so that probe owners or probe makers can freely decide what works best for their cases.
帯域外または帯域内のテクニック、または両方の組み合わせを使用すると、意図またはコンテキストに大きく依存します。このセクションでは、各テクニックの利点と欠点について説明して、プローブの所有者またはプローブメーカーがケースに最適なものを自由に決定できるようにします。
The advantages of using the out-of-band technique are that the probing measurement is not impacted by probe attribution and that it is easy to set up, i.e., by running a web server on a probe device to describe the measurements. Unfortunately, there are some disadvantages too. In some cases, using the out-of-band technique might not be possible due to several conditions: the presence of a NAT, too many endpoints to run a web server on, the probe source IP address cannot be known (e.g., RIPE Atlas [RIPE_ATLAS] probes are sent from IP addresses not owned by the probe owner), dynamic source addresses, etc.
帯域外の手法を使用することの利点は、プローブ測定がプローブの帰属によって影響を受けず、セットアップが簡単であること、つまり、プローブデバイスでWebサーバーを実行して測定値を説明することです。残念ながら、いくつかの欠点もあります。場合によっては、いくつかの条件のために帯域外技術を使用することは不可能かもしれません：NATの存在、Webサーバーをオンにするにはエンドポイントが多すぎると、プローブソースIPアドレスはわかりません（例えば、熟したAtlas[RIPE_ATLAS]プローブは、プローブの所有者が所有していないIPアドレスから送信されます）、動的なソースアドレスなど。
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 primary disadvantage is that it could potentially bias the measurements, since packets with the Probe Description URI might be discarded. For example, data is allowed in TCP segments with the SYN flag [RFC9293] but may change the way they are processed, i.e., TCP segments with the SYN flag containing the Probe Description URI might be discarded. Another example is the Probe Description URI included in a Hop-by-Hop or Destination Options header inside a PadN option. Section 2.1.9.5 of [RFC4942] (an Informational RFC) suggests that a PadN option should only contain 0s and be smaller than 8 octets, thus limiting its use for probe attribution. If a PadN option does not respect the recommendation, it is suggested that one may consider dropping such packets. For example, since version 3.5, the Linux Kernel follows these recommendations and discards such packets.
インバンド技術を使用することの主な利点は、バンド外の手法が実行不可能な場合（上記のように）カバーすることです。主な欠点は、プローブの記述を含むパケットが廃棄される可能性があるため、測定に潜在的にバイアスする可能性があることです。たとえば、データはSynフラグ[RFC9293]を使用したTCPセグメントで許可されていますが、プローブの説明を含むSynフラグを持つTCPセグメントが破棄される場合があります。別の例は、PADNオプション内のホップバイホップまたは宛先オプションヘッダーに含まれるプローブの説明URIです。[RFC4942]（情報RFC）のセクション2.1.9.5は、PADNオプションに0を含み、8オクテットよりも小さいことを示唆しているため、プローブの属性への使用が制限されています。PADNオプションが推奨事項を尊重しない場合、そのようなパケットを削除することを検討することが提案されています。たとえば、バージョン3.5以降、Linuxカーネルはこれらの推奨事項に従い、そのようなパケットを破棄します。
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" the 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 technique alone is less prone to spoofing, the combination with the in-band technique offers a more complete solution.
帯域外のテクニックと帯域内の両方のテクニックを組み合わせることには、大きな利点があります。つまり、との相関関係により、バンドプローブ内のプローブ説明URIを「認証」する間接的な手段として使用できます。バンド外の手法（例：逆DNSルックアップ）。バンド外のテクニックだけではスプーフィングが発生しやすくなりますが、インバンドテクニックとの組み合わせにより、より完全なソリューションが提供されます。
Executing measurement experiences over the global Internet obviously requires ethical consideration, which is discussed in [ANRW_PAPER], especially when unsolicited transit or destination parties are involved.
グローバルなインターネット上で測定経験を実行するには、明らかに倫理的な考慮が必要です。これは、特に未承諾の輸送または目的地が関与している場合、[anrw_paper]で議論されています。
This document proposes a common way to identify the source and the purpose of active probing in order to reduce the potential burden on the unsolicited parties.
この文書は、未承諾の当事者の潜在的な負担を軽減するために、積極的な調査のソースと目的を特定する共通の方法を提案しています。
But there are other considerations to be taken into account, from the payload content (e.g., is the encoding valid?) to the transmission rate (see also [IPV6_TOPOLOGY] and [IPV4_TOPOLOGY] for some probing speed impacts). Those considerations are out of scope of this document.
しかし、ペイロードコンテンツ（例えば、エンコードは有効ですか？）から伝送速度まで、他の考慮事項があります（いくつかの調査速度の影響については[IPv6_Topology]および[IPv4_Topology]も参照）。これらの考慮事項は、このドキュメントの範囲外です。
This document proposes simple techniques for probe attribution. It is expected that only ethical researchers would use them, which would simplify and reduce 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 obtained cannot be blindly trusted. Using these techniques should not mean that a probe can be trusted. Instead, third parties should use this solution to potentially understand the origin and context of such probes. This solution is not perfect, but it provides a way for probe attribution, which is better than no solution at all.
このドキュメントは、プローブの帰属のための簡単な手法を提案しています。倫理的研究者のみがそれらを使用することが期待されています。これにより、インターネット全体でプローブを特定する時間を簡素化して短縮します。実際、これらの手法は、悪意のあるかどうかにかかわらず、誰でも使用できます。つまり、得られた情報は盲目的に信頼できません。これらの手法を使用することは、プローブを信頼できることを意味するものではありません。代わりに、サードパーティはこのソリューションを使用して、そのようなプローブの起源とコンテキストを潜在的に理解する必要があります。このソリューションは完璧ではありませんが、プローブの帰属の方法を提供します。これは、ソリューションがまったくないよりも優れています。
Probe attribution is provided to identify the source and intent of specific probes, but there is no authentication possible for the inline information. Therefore, a malevolent actor could provide false information while conducting the probes or spoof them so that the action is attributed to a third party. In that case, not only would this third party be wrongly accused, but it might also be exposed to unwanted solicitations (e.g., angry emails or phone calls if the malevolent actor used someone else's email address or phone number). As a consequence, the recipient of this information cannot trust it without confirmation. If a recipient cannot confirm the information or does not wish to do so, it should treat the flows as if there were no probe attribution. Note that using probe attribution does not create a new DDoS vector since there is no expectation that third parties would automatically confirm the information obtained.
特定のプローブのソースと意図を識別するためにプローブ属性が提供されますが、インライン情報には認証はありません。したがって、悪意のある俳優は、プローブを実施しながら誤った情報を提供したり、アクションがサードパーティに起因するようにしたりすることができます。その場合、この第三者は誤って非難されるだけでなく、不名誉な訴訟が他の人のメールアドレスまたは電話番号を使用した場合、怒っている電子メールや電話など）にもさらされる可能性があります。結果として、この情報の受信者は、確認なしにそれを信頼することはできません。受信者が情報を確認できない場合、またはそうすることを望まない場合、プローブの帰属がないかのようにフローを扱う必要があります。プローブ属性を使用しても、第三者が取得した情報を自動的に確認するという期待がないため、新しいDDOSベクトルが作成されないことに注意してください。
As the Probe Description URI is transmitted in the clear and as the Probe Description File is publicly readable, Personally Identifiable Information (PII) should not be used for an email address and a phone number; a generic or group email address and phone number should be preferred. Also, the Probe Description File could contain malicious data (e.g., links) and therefore should not be blindly trusted.
プローブの説明があるため、URIはクリアで送信され、プローブ説明ファイルが公開されているため、個人識別可能な情報（PII）は電子メールアドレスと電話番号には使用しないでください。一般的またはグループのメールアドレスと電話番号をお勧めします。また、プローブの説明ファイルには悪意のあるデータ（リンクなど）が含まれている可能性があるため、盲目的に信頼されるべきではありません。
IANA has added the following URI suffix to the "Well-Known URIs" registry in accordance with [RFC8615]:
IANAは、[RFC8615]に従って、「有名なURIS」レジストリに次のURI接尾辞を追加しました。
URI Suffix:
URIサフィックス：
probing.txt
Proving.txt
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9511
RFC 9511
Status:
状態：
permanent
永続パーマネント恒久常任不変永住永久的な一定不変
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC9116] Foudil, E. and Y. Shafranovich, "A File Format to Aid in
Security Vulnerability Disclosure", RFC 9116,
DOI 10.17487/RFC9116, April 2022,
<https://www.rfc-editor.org/info/rfc9116>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[ANRW_PAPER]
Fiebig, T., "Crisis, Ethics, Reliability & a
measurement.network - Reflections on Active Network
Measurements in Academia", DOI 10.1145/3606464.3606483,
July 2023,
<https://pure.mpg.de/rest/items/item_3517635/component/
file_3517636/content>.
[IPV4_TOPOLOGY]
Beverly, R., "Yarrp'ing the Internet: Randomized High-
Speed Active Topology Discovery",
DOI 10.1145/2987443.2987479, November 2016,
<http://www.cmand.org/papers/yarrp-imc16.pdf>.
[IPV6_TOPOLOGY]
Beverly, R., Durairajan, R., Plonka, D., and J. Rohrer,
"In the IP of the Beholder: Strategies for Active IPv6
Topology Discovery", DOI 10.1145/3278532.3278559, October
2018, <http://www.cmand.org/papers/beholder-imc18.pdf>.
[JAMES] Vyncke, É., Léas, R., and J. Iurman, "Just Another
Measurement of Extension header Survivability (JAMES)",
Work in Progress, Internet-Draft, draft-vyncke-v6ops-
james-03, 9 January 2023,
<https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-
james-03>.
[LARGE_SCALE]
Donnet, B., Raoult, P., Friedman, T., and M. Crovella,
"Efficient Algorithms for Large-Scale Topology Discovery",
DOI 10.1145/1071690.1064256, DOI 10.1145/1071690.1064256,
June 2005,
<https://dl.acm.org/doi/pdf/10.1145/1071690.1064256>.
[NCSC] UK NCSC, "The National Cyber Security Centre",
<https://www.ncsc.gov.uk/>.
[NCSC_SCAN_INFO]
UK NCSC, "NCSC Scanning information",
<https://www.ncsc.gov.uk/information/ncsc-scanning-
information>.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", RFC 4942,
DOI 10.17487/RFC4942, September 2007,
<https://www.rfc-editor.org/info/rfc4942>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/info/rfc7872>.
[RIPE_ATLAS]
RIPE Network Coordination Centre (RIPE NCC), "RIPE Atlas",
<https://atlas.ripe.net/>.
[SCAPY] "Scapy", <https://scapy.net/>.
Here are several examples generated by [SCAPY] and displayed in the 'tcpdump' format:
[scapy]によって生成され、「tcpdump」形式で表示されるいくつかの例を次に示します。
IP packet with Probe Description URI inside a Destination Options extension header:
宛先オプションエクステンションヘッダー内のプローブ説明uriを備えたIPパケット：
IP6 2001:db8:dead::1 > 2001:db8:beef::1: DSTOPT 60878 > traceroute:
Flags [S], seq 0, win 8192, length 0
0x0000: 6000 0000 0044 3c40 2001 0db8 dead 0000 `....D<@........
0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................
0x0020: 0000 0000 0000 0001 0605 012c 6874 7470 ...........,http
0x0030: 733a 2f2f 6578 616d 706c 652e 6e65 742f s://example.net/
0x0040: 2e77 656c 6c2d 6b6e 6f77 6e2f 7072 6f62 .well-known/prob
0x0050: 696e 672e 7478 7400 edce 829a 0000 0000 ing.txt.........
0x0060: 0000 0000 5002 2000 2668 0000 ....P...&h..
IP packet with the URI in the data payload of a TCP SYN:
TCP synのデータペイロードでURIを備えたIPパケット：
IP6 2001:db8:dead::1.15581 > 2001:db8:beef::1.traceroute:
Flags [S], seq 0:23, win 8192, length 23
0x0000: 6000 0000 002b 0640 2001 0db8 dead 0000 `....+.@........
0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................
0x0020: 0000 0000 0000 0001 3cdd 829a 0000 0000 ........<.......
0x0030: 0000 0000 5002 2000 c9b7 0000 6d61 696c ....P.......mail
0x0040: 746f 3a6c 6162 4065 7861 6d70 6c65 2e6e to:lab@example.n
0x0050: 6574 00 et.
IP echo request with another URI in the data part of the ICMP ECHO_REQUEST:
ICMP ECHO_REQUESTのデータ部分に別のURIを使用したIPエコー要求：
IP6 2001:db8:dead::1 > 2001:db8:beef::1: ICMP6, echo request, id 0,
seq 0, length 28
0x0000: 6000 0000 001c 3a40 2001 0db8 dead 0000 `.....:@........
0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................
0x0020: 0000 0000 0000 0001 8000 2996 0000 0000 ..........).....
0x0030: 7465 6c3a 2b31 2d32 3031 2d35 3535 2d30 tel:+1-201-555-0
0x0040: 3132 3300 123.
IPv4 echo request with a URI in the data part of the ICMP ECHO_REQUEST:
ICMP ECHO_REQUESTのデータ部分にURIを使用したIPv4エコー要求：
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....@.......
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
0x0030: 6574 00 et.
The authors would like to thank Alain Fiocco, Fernando Gont, Ted Hardie, Mehdi Kouhen, and Mark Townsley for helpful discussions as well as Raphael Leas for an early implementation.
著者は、Alain Fiocco、Fernando Gont、Ted Hardie、Mehdi Kouhen、Mark Townsleyに、有益な議論とラファエルリースに早期実装について感謝したいと思います。
The authors would also like to gracefully acknowledge useful reviews and comments received from Warren Kumari, Jen Linkova, Mark Nottingham, Prapanch Ramamoorthy, Tirumaleswar Reddy.K, Andrew Shaw, and Magnus Westerlund.
著者はまた、Warren Kumari、Jen Linkova、Mark Nottingham、Prapanch Ramamoorthy、Tirumaleswar Reddy.K、Andrew Shaw、Magnus Westerlundから受け取った有用なレビューとコメントを優雅に認めたいと思います。
Éric Vyncke
Cisco
De Kleetlaan 6A
1831 Diegem
Belgium
Email: evyncke@cisco.com
Benoît Donnet
Université de Liège
Belgium
Email: benoit.donnet@uliege.be
Justin Iurman
Université de Liège
Belgium
Email: justin.iurman@uliege.be