Reverse path forwarding

**Reverse path forwarding **（リバースパスフォワーディング、RPF）は、IPネットワークでマルチキャストパケットを転送するためのアルゴリズムのひとつである。
マルチキャストルーティングではパケットをルーティング・ループを起こすことなく転送でき、ユニキャストルーティングではIPアドレススプーフィングを防止できる。2012年2月現在、シスコシステムズ、ジュニパーネットワークス、ヤマハ、アライドテレシスがRPFに対応するルーターを発売している。

## マルチキャストRPF
マルチキャストRPF（典型的には単にRPFと表記される）は、ルーティング・ループを起こすことなくマルチキャストパケットを転送するため、Multicast Source Discovery Protocol （MSDP）やSparse multicast （PIM-SM）といったマルチキャストルーティングプロトコルとともに利用する。マルチキャストルーティングでは、トラフィックを転送するかどうかの判断は送信元アドレスを基に行う。これは、ユニキャストルーティングでは宛先アドレスを基に転送可否の判断を行うことと対称的である。ルーティングにはマルチキャスト専用のルーティングテーブルか、ユニキャスト用のルーティングテーブルを利用する。

マルチキャストパケットがルーターのインタフェースに入ると、ルーターは当該インタフェースから到達可能なネットワークのリストを検索する。ルーターが「マルチキャストパケットの送信元IPアドレス」が「自らのルーティングテーブルに」存在することを発見すると、パケットはマルチキャストグループに参加しているその他のインタフェースにマルチキャストで転送される。ルーティングテーブルに送信元IPアドレスが存在しない場合、パケットは捨てられる。結果として、パケットが転送されるか否かはパケットの前向経路（フォワードパス, forward path）ではなく、*逆行経路（リバースパス, reverse path）*によって決まる。RPFルーターはルーターのインタフェースに到達するパケットでパケットの送信元についてルーティングエントリがあるものだけを転送するため、ルーティングループを形成しない。このチェックのことを**RPFチェック**と言う。

冗長構成のマルチキャストトポロジーでは、同一のマルチキャストパケットが同一のルーターの別々のインタフェースに到達する可能性があるため、パケットを転送するか否かの判断にRPFチェックが必須となる。仮に2つのインタフェースを持つルーターが、インタフェースAに到達した全てのパケットをインタフェースBに転送するとする。インタフェースBに到達した全てのパケットは同様にインタフェースAに転送するとする。この場合、両方のインタフェースが同一のパケットを受信すると、古典的なルーティングループが発生し、IPの生存時間 （Time to live, TTL）が尽きるまで両方向に向けてパケットが転送され続けてしまうだろう。いつかはTTLが尽きるとしても、ルーティングループが発生すると、少なくとも一時的にはネットワークの速度低下を招く。ルーティングループが起きる可能性はできる限り最小にしなければならない。

RPFチェックの前提条件は以下の2点である。

* *ユニキャストルーティングテーブルが正確、かつ収束していること。*RPFチェックの正常動作はユニキャストルーティングテーブルに依存する。
* *送信者がルーターに到達するための経路（フォワードパス）とルーターから送信者を逆にたどった経路（リバースパス）が対称的であること。*この前提が成立しない場合、RPFチェックは送信者からルーターまでの最短経路（ショーテストパス、shortest path）上のマルチキャストトラフィックを拒否する。このため、マルチキャストツリーが最適状態とならない。

リンクが片方向（uni-directional）である場合、リバースパスアプローチは完全に失敗する。

## ユニキャストRPF （uRPF）
に定義されているユニキャストRPF （Unicast RPF, uRPF）は、「既知の『無効なネットワーク』からのトラフィックは、インタフェースで受け付けられるべきでない。そもそもそのようなトラフィックが生成されていないはずだから」とした点が発展的である。で見られる原案は「（で定義される）プライベートアドレスを送信元とするトラフィックをインタフェース上でブロックする」というものであった。多くの組織にとって（使用されていることが明らかでない限り）プライベートアドレスを伝播する必要はないはずであるから、送信元をプライベートアドレスとしたトラフィックを無効としてブロックするのは合理的である。

サービス拒否攻撃、分散型サービス拒否攻撃、ネットワークスキャンでスキャン元を隠すなどのために、IPアドレススプーフィングが一般的に利用される。しかしuRPFを利用すれば、偽の送信元アドレスであることが明らかなパケットをブロックできる。これでIPアドレススプーフィングを阻止することができるので、インターネットバックボーンにとって多大な恩恵となる。

uRPFは、「全てのルーターは、各自が保持しているルーティング情報ベース （Routing Information Base, RIB）か転送情報ベース （Forwarding Information Base, FIB）を利用して、インタフェースに到達するであろう送信者アドレスをより厳しく制限すべきである」という基本思想を劇的に押し広げた。送信元アドレスからルーターへの最善ルート（Best route）を通って到着した場合にのみパケットが転送されるので、以下が成り立つ。
# インタフェースに到達したパケットは、（おそらく）有効なホストから届いたものである。なぜなら、対応するエントリがルーティングテーブルに存在するからである。
# 入力インタフェースを経由して到達*できない*送信元アドレスをセットされたパケットは、通常利用に影響を与えることなく捨てられる。これは、当該パケットが設定ミスがあるか悪意ある送信元からのものであると思われるためである。

以下に示すような「対称的なルーティング」では、uRPFは大きな懸念なく実装できるだろう。
# パケットが転送される前向経路と逆行経路は同じであるはずだ。
# ネットワークエッジへのリンクがただ1つである。
ルーターのインタフェースが「シングルホームのネットワーク」と「端末の存在するサブネット」に接続されていて、ルーティングが確実に対称的である場合、当該インタフェースにRPFを実装すれば特に有益である。できる限り送信者に近い場所でuRPFを利用すれば、スプーフィングされたトラフィックがインターネット接続の帯域を利用したり、RPFが構成されていないルーターに到達して転送されてしまったりすることを防げるからである。

しかし、比較的大きなインターネットバックボーンではルーティングが非対称な場合がある。この場合、送信者がルーターに到達するための最善ルートをルーティングテーブルが保持していることを期待できないことがある。ルーティングテーブルは最善なフォワードパスを規定するが、それを逆行すれば最善なリバースパスになるのはルーティングが対称的な場合だけだ。ルーティングが非対称なケースは一般的なだけに、問題のないトラフィックが誤ってフィルタリングされることを防ぐため、uRPFを実装する際はルーティングが非対称になる可能性について十分な注意が必要である。

なお、デフォルトルートを使用中のデバイスは、デフォルトルートが指し示すインタフェース上ではuRPFを利用できない。送信元にかかわらずすべてのパケットが当該インタフェースで許可されてしまうことが理由である。uRPFはで定義される水準すら達成できないであろう。

は「この送信元アドレスは入力インタフェースに対応するルーティングテーブルに必ず記録されているはずだ」というこの基本概念を拡張して**Strict Reverse Path Forwarding （厳密なリバースパスフォワーディング, Strict RPF）**とした。ある程度経路が非対称な場合でもStrict RPFを利用するメリットがある例も挙げられている。

### Strictモード（Strictチェックモード）
Strictモードでは、受信するパケットはFIBと照査され、パケットを*受信した*インタフェースが最適のリバースパスでない場合、チェックは失敗する。既定ではチェックを通過しなかったパケットは捨てられる。

### Feasibleモード
FeasibleモードではFIBが任意のIPアドレスに対するオルタネートルートを複数保持する。パケットを*受信した*インタフェースが当該IPアドレスに関連づけられた経路と一致する場合、パケットは転送される。一致しない場合はパケットは捨てられる。

### Looseモード
Looseモードでは受信するパケットの送信元アドレスがFIBと照査される。ルーター上の*どの*インタフェースからも送信元アドレスに到達できない場合にのみ、パケットは捨てられる。

## uRPFのFを「フィルタリング」とする誤解
ユニキャストルーティングにおいては特に、RPFをReverse Path **Filtering（フィルタリング）**の略とする**誤った**定義が流布している。RPFがで示されるようにユニキャストルーティングとともに使われる場合、トラフィックの転送可否はRPFチェックに通過するか否かを基に決まる。これを「RPFチェックに失敗したので、パケットがフィルタリングされた」と受け取ったために生じた誤解であろう。によれば、正しくは「RPFチェックを通過すればトラフィックが**Forwarding（転送）される**」である。
ジュニパーネットワークスの文書、シスコシステムズの文書、OpenBSDプロジェクトの文書は、この点を正しく述べている。ユニキャストでのRPFの利用について定義したが最も重要である。

uRPFは受信トラフィックに**フィルタリング**機構を用いるが、リバースパス**フォワーディング**の影響を受けるのである。

## 脚注


## 参考文献



## 外部リンク

* RFC 2827
* RFC 3704
* Juniper - Configuring uRPF（英語）
* Cisco - Understanding uRPF（英語）
* Multicast Reverse Forwarding（RPF）（英語）
* OpenBSD - Enabling uRPF in pf（英語）
* Juniper Networks on multicast RPF（英語）

* 独立行政法人情報処理推進機構によるRFC 2827の日本語訳
* 独立行政法人情報処理推進機構によるRFC 3704の日本語訳
* シスコシステムズ - IP ルーティングに関する FAQ（日本語）
* 『IP マルチキャスト技術』（Internet Week '99における藤井直人氏の講演レジュメ（PDF、日本語））
* 『ネットワークエンジニアとして』のマルチキャストRPF解説ページ（日本語）
* 日経ITPro『シスコ資格：CCNPへの道（BSCI編）マルチキャスト編第4回　PIMを知る』