Zenn
🔥

RFC 8335: PROBE: インタフェースをプローブするためのユーティリティ

2024/12/18に公開
RFC
tech

概要

本文書では、PROBEと呼ばれるネットワーク診断ツールについて説明する。PROBEは、プローブされるインタフェースの状態を照会できるという点でPINGと似ているが、プローブするインタフェースとプローブされるインタフェースとの間に双方向の接続を必要としないという点で PINGとは異なる。その代わり、PROBEではプローブするインタフェースとプロキシ・インタフェースとの間に双方向の接続が必要である。プロキシ・インタフェースはプローブされるインタフェースと同じノード上に存在することも、プローブされるインタフェースが直接接続されているノード上にも存在することもできる。本文書は、RFC 4884を更新するものである。

本文書の位置付け

本文書はインターネット標準化過程の文書である。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、<http://www.rfc-editor.org/info/rfc8335>で入手できる。

著作権表示

Copyright (c) 2018 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(<https://trustee.ietf.org/license-info>)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

ネットワーク・オペレータは、2つのインタフェース間の双方向の接続性を検証するために、PING[RFC2151]を使用する。本文書ではこれらのインタフェースを、プローブするインタフェースとプローブされるインタフェースと呼ぶ。PINGは、プローブするインタフェースからプローブされるインタフェースにICMP[RFC792] [RFC4443]のエコー要求メッセージを送信する。プローブするインタフェースはプローブするノード上にあり、プローブされるインタフェースはプローブされるノード上にある。

プローブされるインタフェースがICMPエコー要求メッセージを受信すると、ICMPエコー応答を返す。プローブするインタフェースがICMPエコー応答を受信すると、プローブするインタフェースとプローブされるインタフェース間の双方向接続性が検証される。具体的には、以下のことが検証されたことになる。

  • プローブを送信したノードがプローブされたインタフェースに到達できること。
  • プローブされたインタフェースがアクティブであること。
  • プローブされたノードがノードが、プローブを送信したインタフェースに到達できること。
  • プローブを送信したインタフェースがアクティブであること。

本文書では、PROBEと呼ばれるネットワーク診断ツールを説明する。PROBEは、プローブされたインタフェースの状態を照会できるという点でPINGと似ているが、プローブするインタフェースとプローブされるインタフェース間の双方向接続を必要としないという点でPINGとは異なる。その代わり、PROBEは、プローブするインタフェースとプロキシ・インタフェース間の双方向接続を必要とする。プロキシ・インタフェースは、プローブされるインタフェースと同じノード上に存在することも、プローブされるインタフェースが直接接続されているノード上に存在することもできる。この文書のセクション5では、この特性が役立つシナリオについて説明する。

PINGと同様に、PROBEもプローブするノードで実行される。これは、ICMP拡張エコー要求メッセージを、プローブするインタフェースと呼ばれるローカル・インタフェースからプロキシ・インタフェースに送信する。プロキシ・インタフェースは、プロキシ・ノード上に存在する。

ICMP拡張エコー要求にはICMP拡張構造が含まれ、ICMP拡張構造にはインタフェース識別オブジェクトが含まれる。インタフェース識別オブジェクトは、プローブされるインタフェースを識別する。プローブされるインタフェースは、プロキシ・ノード上に存在することも、プロキシ・ノードに直接接続することもできる。

プロキシ・インタフェイスがICMP拡張エコー要求を受信すると、プロキシ・ノードはアクセス制御手順を実行する。アクセスが許可されると、プロキシ・ノードはプローブされたインタフェースの状態を判定し、ICMP拡張エコー応答メッセージを返す。ICMP拡張エコー応答は、プローブされたインタフェースの状態を示す。

プローブされたインタフェースがプロキシ・ノード上にある場合、PROBEは、oper-status [RFC7223]を判定するのと同じように、プローブされたインタフェースの状態を判定する。oper-statusが「up」(1)に等しい場合、PROBEはプローブされたインタフェースがアクティブであると報告する。それ以外の場合、PROBEはプローブされたインタフェースが非アクティブであると報告する。

プローブされたインタフェースがプロキシ・ノードに直接接続されているノード上にあり、プローブされたインタフェースがIPv4アドレス解決プロトコル(ARP)テーブル [RFC826]またはIPv6近隣キャッシュ [RFC4861]に表示される場合、PROBEはインタフェースの到達性を報告する。それ以外の場合、PROBEはテーブル・エントリが存在しないことを報告する。

1.1.用語

本文書は、以下の用語を使用する:

  • プローブするインタフェース: ICMP拡張エコー要求を送信するインタフェース。
  • プローブするノード: プローブするインタフェースが存在するノード。
  • プロキシ・インタフェース: ICMP拡張エコー要求メッセージを送信するインタフェース。
  • プロキシ・ノード: プロキシ・インタフェースが存在するノード。
  • プローブされるインタフェース: 状態が照会されるインタフェース。
  • プローブされるノード: プローブされるインタフェースが存在するノード。プロキシ・インタフェースとプローブされるインタフェースが同じノードに存在する場合、プロキシ・ノードはプローブされるノードでもある。そうでなければ、プロキシ・ノードはプローブされるノードに直接接続されている。

1.2.要件言語

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

2. ICMP拡張エコー要求

ICMP拡張エコー要求メッセージは、ICMPv4とICMPv6の両方で定義されている。他のICMPメッセージと同様に、ICMP拡張エコー要求メッセージはIPヘッダにカプセル化される。拡張エコー要求メッセージのICMPv4バージョンはIPv4ヘッダにカプセル化され、ICMPv6バージョンはIPv6ヘッダにカプセル化される。

図1にICMP 拡張エコー要求メッセージを示す。

fig1
図1: ICMP拡張エコー要求メッセージ

IPヘッダ・フィールド:

  • 送信元アドレス: 送信元アドレスはプローブ・インタフェースを識別する。有効なIPv4またはIPv6ユニキャスト・アドレスでなければならない(MUST)。

  • 宛先アドレス: 宛先アドレスはプロキシ・インタフェースを識別する。ユニキャスト・アドレスでなければならない(MUST)。

ICMPフィールド:

  • タイプ: 拡張エコー要求。ICMPv4の値は42である。ICMPv6の値は160である。

  • コード: 0に設定しなければならず(MUST)、受信時に無視しなければならない(MUST)。

  • チェックサム: ICMPv4については、RFC 792を参照のこと。ICMPv6については、RFC 4443を参照のこと。

  • 識別子: 拡張エコー応答を拡張エコー要求にマッチさせるための識別子。0の場合もある。

  • シーケンス番号: 拡張エコー応答を拡張エコー要求にマッチさせるためのシーケンス番号。0の場合もある。

  • 予約済み: このフィールドは0に設定し、受信時に無視しなければならない(MUST)。

  • L(ローカル): プローブされたインタフェースがプロキシ・ノード上にある場合は、Lビットが設定される。プローブされたインタフェースがプロキシ・ノードに直接接続されている場合は、Lビットはクリアされる。

  • ICMP拡張構造: ICMP拡張構造は、プローブされたインタフェースを識別する。

[RFC4884]のセクション7はICMP拡張構造を定義している。RFC 4884によると、拡張構造は1つの拡張ヘッダと、それに続く1つ以上のオブジェクトを含む。ICMP拡張エコー要求メッセージに適用する場合、ICMP拡張構造にはインタフェース識別オブジェクトのインスタンス(セクション2.1参照)を1 つだけ含めなければならない(MUST)。

Lビットが設定されている場合、インタフェース識別オブジェクトは、プローブされたインタフェースを名前、インデックス、またはアドレスで識別できる。Lビットがクリアされている場合、インタフェース識別オブジェクトは、プローブされたインタフェースをアドレスで識別しなければならない(MUST)。

インタフェース識別オブジェクトがプローブされたインタフェースをアドレスで識別する場合、そのアドレスはどのアドレス・ファミリーのメンバーにすることもできる。例えば、ICMPv4拡張エコー要求メッセージは、プローブされたインタフェースをIPv4、IPv6、またはIEEE 802アドレスで識別するインタフェース識別オブジェクトを伝送することができる。同様に、ICMPv6拡張エコー要求メッセージは、プローブされたインタフェースをIPv4、IPv6、またはIEEE 802アドレスで識別するインタフェース識別オブジェクトを伝送することができる。

2.1. インタフェース識別オブジェクト

インタフェース識別オブジェクトは、プローブされたインタフェースを名前、インデックス、またはアドレスで識別する。他のICMP拡張オブジェクトと同様に、オブジェクト・ヘッダとオブジェクト・ペイロードを含む。オブジェクト・ヘッダには以下のフィールドが含まれる:

  • Class-Num: インタフェース識別オブジェクト。値は3である。

  • C-Type: (1) 名前によるインタフェースを識別、(2) インデックスでインタフェースを識別、(3) アドレスでインタフェースを識別する。

  • Length: オブジェクト・ヘッダとオブジェクト・ペイロードを含む、オクテット単位で測定されたオブジェクトの長さ。

インタフェース識別オブジェクトがプローブされたインタフェースを名前で識別する場合、オブジェクト・ペイロードは[RFC7223]で定義されているインタフェース名でなければならない(MUST)。オブジェクト・ペイロードが32ビット境界で終了しない場合、ASCII NULL文字でパディングしなければならない。

インタフェース識別オブジェクトがプローブされたインタフェースをインデックスで識別する場合、長さは8で、ペイロードにはif-index[RFC7223]を含む。

インタフェース識別オブジェクトがプローブされたインタフェースをアドレスで識別する場合、ペイロードは図2のようになる。

fig2
図2: インタフェース識別オブジェクト - Cタイプ3ペイロード

ペイロード・フィールドは以下のように定義されている:

  • アドレス・ファミリ識別子(AFI): この16ビット・フィールドは、アドレス・フィールドで表されるアドレスのタイプを識別する。このフィールドでは、アドレス・ファミリー番号の IANAレジストリ(https://www.iana.org/assignments/address-family-numbersから入手可能)にあるすべての値が有効である。

  • アドレス長: アドレス・フィールドに含まれる有効バイト数。(アドレス・フィールドには、有効バイトとパディング・バイトを含む。)

  • 予約済み: このフィールドは0に設定し、受信時に無視しなければならない(MUST)。

  • アドレス: この可変長フィールドは、プローブされたインタフェースに関連付けられたアドレスを表す。アドレス・フィールドが32ビット境界で終了しない場合は、それはゼロでパディングしなければならない(MUST)。

3. ICMP拡張エコー応答

ICMP拡張エコー応答メッセージは、ICMPv4とICMPv6の両方で定義されている。他のICMPメッセージと同様に、ICMP拡張エコー応答メッセージはIPヘッダにカプセル化される。拡張エコー応答メッセージのICMPv4バージョンはIPv4ヘッダにカプセル化され、ICMPv6バージョンはIPv6ヘッダーにカプセル化される。

図3はICMP拡張エコー応答メッセージを示す。

fig3
図3: ICMP拡張エコー応答メッセージ

IPヘッダ・フィールド:

  • 送信元アドレス: 呼び出し元の拡張エコー要求メッセージの宛先アドレス・フィールドからコピーされる。

  • 宛先アドレス: 呼び出し元の拡張エコー要求メッセージの送信元アドレス・フィールドからコピーされる。

ICMPフィールド:

  • タイプ: 拡張エコー応答。ICMPv4の値は43である。ICMPv6の値は161である。

  • コード: 値は(0)エラーなし、(1)不正なクエリ形式、(2)そのようなインタフェースはない、(3)そのようなテーブル・エントリはない、(4)クエリを満たすインタフェースが複数ある。

  • チェックサム: ICMPv4については、RFC 792を参照のこと。ICMPv6については、RFC 4443を参照のこと。

  • 識別子: 呼び出し元の拡張エコー要求パケットの識別子フィールドからコピーされる。

  • シーケンス番号: 呼び出し元の拡張エコー要求パケットのシーケンス番号フィールドからコピーされる。

  • 状態: コードが0でなければ、このフィールドは0に設定され、受信時に無視しなければならない(MUST)。同様に、プローブされたインタフェースがプロキシ・ノード上にある場合、このフィールドは0に設定され、受信時に無視しなければならない(MUST)。それ以外の場合、このフィールドは、プローブされたインタフェースに関連付けられたARPテーブルまたは近隣キャッシュ・エントリの状態を反映する。値は、(0)予約済み、(1)不完全、(2)到達可能、(3)古い、(4)遅延、(5)プローブ、そして(6)失敗である。

  • Res(予約): このフィールドは0に設定され、受信時に無視しなければならない(MUST)。

  • A (アクティブ): コードが0で、プローブされたインタフェースがプロキシ・ノード上に存在し、プローブされたインタフェースがアクティブな場合、Aビットを設定する。それ以外の場合、Aビットはクリアされる。

  • 4 (IPv4): Aビットが設定され、プローブされたインタフェースでIPv4が実行されている場合は、ビット4が設定される。それ以外の場合、ビット4はクリアされる。

  • 6 (IPv6): Aビットが設定され、プローブされたインタフェースでIPv6が実行されている場合は、ビット6が設定される。それ以外の場合、ビット6はクリアされる。

4. ICMPメッセージ処理

ノードがICMP拡張エコー要求メッセージを受信し、以下のいずれかの条件が当てはまる場合、ノードは着信メッセージを黙って破棄しなければならない(MUST)。

  • ノードがICMP拡張エコー要求メッセージを認識していない。

  • ノードがICMP拡張エコー機能を明示的に有効にしていない。

  • 着信ICMP拡張エコー要求は、着信ICMP拡張エコー要求のL ビット設定に対して明示的に承認されていない送信元アドレスを伝える。

  • 着信ICMP拡張エコー要求は、着信ICMP拡張エコー要求タイプ(つまり、ifName、IfIndex、またはアドレス)に対して明示的に認可されていない送信元アドレスを伝える。

  • 着信メッセージの送信元アドレスがユニキャスト・アドレスではない。

  • 着信メッセージの宛先アドレスがマルチキャスト・アドレスである。

それ以外の場合、ノードがICMPv4拡張エコー要求を受信すると、ICMP拡張エコー応答を以下のようにフォーマットしなければならない(MUST):

  • Don't Fragment (DF)フラグは1

  • More Fragmentsフラグは0

  • Fragment Offsetは0

  • TTLは255

  • プロトコルはICMP

ノードがICMPv6 拡張エコー要求を受信した場合、ICMP拡張エコー応答を以下のようにフォーマットしなければならない(MUST):

  • ホップ制限は255

  • ネクスト・ヘッダはICMPv6

いずれの場合も、応答ノードは以下の操作を行わなければならない(MUST)。

  • 拡張エコー要求メッセージの送信元アドレスを拡張エコー応答の宛先アドレスにコピーする。

  • 拡張エコー要求メッセージの宛先アドレスを拡張エコー応答の送信元アドレスにコピーする。

  • DiffServコードポイントをCS0[RFC4594]に設定する。

  • ICMPタイプを拡張エコー応答に設定する。

  • 拡張エコー要求メッセージの識別子を拡張エコー応答にコピーする。

  • 拡張エコー要求メッセージのシーケンス番号を拡張エコー応答にコピーする。

  • セクション 4.1の説明に従ってコード・フィールドを設定する。

  • 状態フィールドを0に設定する。

  • Aビット、ビット4、ビット6をクリアする。

  • (1)コード・フィールドが、(0)エラーなしに等しく、(2)Lビットが設定され、(3)プローブされたインタフェースがアクティブである場合、Aビットを設定する。また、必要に応じてビット4とビット6を設定する。

  • コード・フィールドが、(0)エラーなしで、Lビットがクリアされている場合、プローブされたインタフェースを表すARPテーブルまたはネイバー・キャッシュ・エントリの状態を反映するために、状態フィールドを設定する。

  • チェックサムを適切に設定する。

  • ICMP拡張エコー応答を宛先に転送する。

4.1. コード・フィールドの処理

以下の条件のいずれかが当てはまる場合、コード・フィールドに(1) 不正なクエリを設定しなければならない(MUST):

  • ICMP拡張エコー要求にICMP拡張構造が含まれていない。

  • ICMP拡張構造は、正確に1つのインタフェース識別オブジェクトを含まない。

  • Lビットがクリアされており、インタフェース識別オブジェクトがifNameまたはifIndexによってプローブされたインタフェースを識別する。

  • それ以外の場合、クエリは不正な形式である。

Lビットが設定されていて、ICMP拡張構造がプロキシ・ノードに存在するインタフェースを識別しない場合、コード・フィールドには(2)そのようなインタフェースはないを設定しなければならない(MUST)。

Lビットがクリアされていて、インタフェース識別オブジェクトで見つかったアドレスがIPv4アドレス解決プロトコル(ARP)テーブルにも、IPv6近隣キャッシュにも表示されない場合、コード・フィールドを(3)そのようなテーブル・エントリはないに設定しなければならない(MUST)。

以下のいずれかの条件が当てはまる場合、コード・フィールドは(4)複数のインタフェースがクエリを満たしているに設定しなければならない(MUST)。

  • Lビットが設定されており、ICMP拡張構造がプロキシ・ノードに存在する複数のインタフェースを識別する。

  • Lビットがクリアされ、インタフェース識別オブジェクトで見つかったアドレスが複数のIPv4 ARPまたはIPv6近隣キャッシュ・エントリにマップされる。

それ以外の場合、コード・フィールドは(0)エラーなしに設定しなければならない(MUST)。

5. ユースケース

以下に列挙するシナリオでは、ネットワーク・オペレータはプローブされたインタフェースの状態を判断するためにPROBEを使用できるが、同じ目的でPINGを使用することはできない。すべてのシナリオで、プローブ・インタフェースとプロキシ・インタフェース間の双方向接続を想定する。ただし、プローブ・インタフェースとプローブされたインタフェース間の双方向接続は欠けている。

  • プローブされたインタフェースに番号がない。

  • プローブするインタフェースとプローブされたインタフェースは、互いに直接接続されていない。プローブされたインタフェースにはIPv6リンクローカル・アドレスを持っているが、グローバルにスコープされたアドレスは持っていない。

  • プローブするインタフェースはIPv4のみを実行し、プローブされたインタフェースはIPv6のみを実行する。

  • プローブするインタフェースはIPv6のみを実行し、プローブされたインタフェースはIPv4のみを実行する。

  • 経路がないため、プローブ・ノードはプローブされたインタフェースに到達できない。

6. RFC 4884の更新

[RFC4884]のセクション4.6では、拡張可能なICMPメッセージ(つまり、ICMP拡張構造を伝送できるメッセージ)のリストが記載されている。本文書では、ICMP拡張エコー要求メッセージとICMP拡張エコー応答メッセージをこのリストに追加する。

7. IANA の考慮事項

IANAは以下の対応を行なった:

  • 「ICMPタイプ番号」レジストリに以下を追加した:

    42 拡張エコー要求

    「タイプ42 - 拡張エコー要求」サブレジストリに以下を追加した:

    (0) エラーなし

  • 「ICMPv6タイプ番号」レジストリに以下を追加した:

    160 拡張エコー要求
    ICMPv6は情報メッセージとエラー・メッセージを区別し、これは情報メッセージであるため、値は128 ～ 255の範囲から割り当てられている。

    「タイプ160 - 拡張エコー要求」サブレジストリに以下を追加した:

    (0) エラーなし

  • 「ICMPタイプ番号」レジストリに以下を追加した:

    43 拡張エコー応答

    「タイプ43 - 拡張エコー応答」サブレジストリに以下を追加した:

    (0) エラーなし
    (1) 不正なクエリ
    (2) そのようなインタフェースはない
    (3) そのようなテーブル・エントリはない
    (4) 複数のインタフェースがクエリを満たしている

  • 「ICMPv6タイプ番号」レジストリに以下を追加した:

    161 拡張エコー応答
    ICMPv6は情報メッセージとエラー・メッセージを区別し、これは情報メッセージであるため、値は128 ～ 255の範囲から割り当てられている。

    「タイプ 161 - 拡張エコー応答」サブレジストリに以下を追加した:

    (0) エラーなし
    (1) 不正なクエリ
    (2) そのようなインタフェースはない
    (3) そのようなテーブル・エントリはない
    (4) 複数のインタフェースがクエリを満たしている

  • 「ICMP拡張オブジェクト・クラスとクラス・サブタイプ」レジストリに以下を追加した:

    (3) インタフェース識別オブジェクト

    「サブタイプ - クラス3 - インタフェース識別オブジェクト」サブレジストリに以下のCタイプを追加した:

    (0) 予約済み
    (1) 名前でインタフェースを識別
    (2) インデックスでインタフェースを識別
    (3) アドレスでインタフェースを識別

    Cタイプの値は、0～255の範囲で先着順(FCFS)方式で割り当てられる。

上記のすべてのコードは、0～255の範囲でFCFS方式で割り当てられる。

8. セキュリティに関する考慮事項

以下は、PROBEの正当な使用法である:

  • インタフェースの動作状態を判別する。

  • インタフェースでアクティブなプロトコル(IPv4またはIPv6など)を判別する。

ただし、悪意のある当事者はPROBEを使用して追加情報を取得することができる。例えば、悪意のある当事者はPROBEを使って、インタフェース名を検出することができる。インタフェース名を検出した悪意のある当事者は、追加情報を推測することができる。追加情報には以下の情報が含まれる。

  • インタフェースの帯域幅

  • インタフェースをサポートするデバイスのタイプ (ベンダIDなど)

  • 上記のデバイスを実行するオペレーティング・システムのバージョン

このリスクを理解しているネットワーク・オペレータは、ICMP拡張エコー機能へのアクセスを制限するポリシーを確立する。これらのポリシーを適用するには、ICMP拡張エコー機能をサポートするノードが以下の構成オプションをサポートしなければならない(MUST):

  • ICMP拡張エコー機能を有効/無効にする。デフォルトでは、ICMP拡張エコー機能を無効にする。

  • 有効なLビット設定を定義する。デフォルトでは、Lビットを設定するオプションは有効になっており、Lビットをクリアするオプションは無効になっている。

  • 有効なクエリ・タイプを定義する(名前、インデックス、またはアドレスによる)。デフォルトでは、すべてのクエリ・タイプが無効になっている。

  • 有効なクエリ・タイプごとに、ICMP拡張エコー要求メッセージが許可されるプレフィックスを定義する。

  • 各インタフェースごとに、ICMPエコー要求メッセージが受け入れられるかどうかを決定する。

ノードがサポートするように設定されていないICMP拡張エコー要求メッセージを受信した場合、ノードはそのメッセージを黙って破棄しなければならない(MUST)。詳細については、セクション4を参照のこと。

プローブは、ある仮想プライベート・ネットワーク(VPN)に関する情報を別のVPNに漏らしてはならない。したがって、ノードが ICMP拡張エコー要求を受信し、プロキシ・インタフェースがプローブされたインタフェースとは異なるVPNにある場合、ノードは(2)そのようなインタフェースはないに等しいエラー・コードを持つICMP拡張エコー応答を返さなければならない(MUST)。

ローカル・リソースを保護するために、実装は着信ICMP拡張エコー要求メッセージをレート制限すべきである(SHOULD)。

9. 参考文献

9.1. 引用規格

[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.

[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[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>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, <https://www.rfc-editor.org/info/rfc4884>.

[RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, <https://www.rfc-editor.org/info/rfc7223>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. 参考規格

[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", FYI 30, RFC 2151, DOI 10.17487/RFC2151, June 1997, <https://www.rfc-editor.org/info/rfc2151>.

[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.

付録A. PROBEアプリケーション

PROBEアプリケーションは入力パラメータを受け取り、カウンタを設定し、カウンタが0になったときに終了するループに入る。ループの各反復で、PROBEはICMP拡張エコー要求を発行し、カウンタをデクリメントし、タイマーを設定して待機する。ICMP拡張エコー要求には、識別子とシーケンス番号が含まれる。

同じ識別子とシーケンス番号を持つICMP拡張エコー応答が到着すると、PROBEはそのメッセージによって返された情報をユーザに中継する。ただし、ループの各反復では、拡張エコー応答メッセージが到着するかどうかに関係なく、PROBEはタイマーが期限切れになるまで待機する。

PROBEは以下のパラメータを受け付ける:

  • カウント

  • 待機

  • プローブするインタフェース・アドレス

  • ホップカウント

  • プロキシ・インタフェース・アドレス

  • ローカル

  • プローブされるインタフェース識別子

カウントは正の整数で、デフォルト値は3である。カウントは、PROBEが上記のループを繰り返す回数を指定する。

待機は正の整数で、最小値とデフォルト値は1である。待機は、上記のタイマーの継続時間を秒単位で指定する。

プローブするインタフェース・アドレスは、ICMP拡張エコー要求の送信元アドレスを指定する。プローブするインタフェース・アドレスはユニキャスト・アドレスでなければならず(MUST)、プローブするノードに存在するインタフェースを識別しなければならない(MUST)。

プロキシ・インタフェース・アドレスは、ICMP拡張エコー要求メッセージが送信されるインタフェースを識別する。これはIPv4またはIPv6ユニキャスト・アドレスでなければならない(MUST)。IPv4アドレスの場合、PROBEはICMPv4メッセージを送信する。IPv6アドレスの場合、PROBEはICMPv6メッセージを送信する。

ローカルはブール値である。プロキシ・インタフェースとプローブするインタフェースの両方が同じノードに存在する場合はTRUEになる。それ以外の場合はFALSEである。

プローブされるインタフェース識別子は、プローブされるインタフェースを識別する。これは以下のいずれかである:

  • インタフェース名

  • 任意のアドレス・ファミリー(例: IPv4、IPv6、IEEE 802、48ビットMAC、または64ビットMAC)のアドレス。または

  • if-index

プローブされたインタフェース識別子がアドレスの場合、プロキシ・インタフェース・アドレスと同じアドレス・ファミリーである必要はない。例えば、PROBEはIPv4のプロキシ・インタフェース・アドレスとIPv6のプローブされたインタフェース識別子を受け付ける。

謝辞

ソウミニ・ヴァラダン、ジェフ・ハース、カルロス・ピニャータロ、ジョナサン・ルーニー、デーブ・ターラー、ミキオ・ハラ、ジョエル・ハルパーン、ヤロン・シェファー、ステファン・ウィンター、ジャン＝ミシェル・コンブ、 アマンダ・バーバー、およびジョー・タッチには、本文書を丁寧にレビューしていただいたことに感謝する。

著者のアドレス

ロン・ボニカ
Juniper Networks
2251 Corporate Park Drive
Herndon, Virginia 20171
アメリカ合衆国
メール: rbonica@juniper.net

レジー・トーマス
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore, Karnataka 560103
インド
メール: rejithomas@juniper.net

ジェン・リンコバ
Google
1600 Amphitheatre Parkway
Mountain View, California 94043
アメリカ合衆国
メール: furry@google.com

クリス・レナート
Verizon
22001 Loudoun County Parkway
Ashburn, Virginia 20147
アメリカ合衆国
メール: chris.lenart@verizon.com

モハメド・ブカデール
Orange
Rennes 35000
フランス
メール: mohamed.boucadair@orange.com

更新履歴

  • 2024.12.11
GitHubで編集を提案

Discussion