dorapon2000’s diary

忘備録的な。セキュリティとかネットワークすきです。

Path MTU Discoveryの問題と実際

Path MTU DiscoveryのIPv4IPv6のどちらの視点でもまとめました。

Path MTU Discovery

インターフェースごとのMTUの違いを解決する方法として、(1) ルータ上でのフラグメンテーションと、(2) 送信元でのフラグメンテーションの2種類の方法があります[1]。IPv4ではDFフラグのon/offで両方でき、IPv6では仕様により後者の方法しかとれません。

(1) IPv4はルータ上で次のリンクのMTUがパケットサイズよりも小さければ、パケットを分割します。

(2) 適当なMTU値で送り、ICMPメッセージが返ってきた場合、そのMTU値に分割して再送します。ICMPv4の場合type 3, code 4「Fragmentation Needed」、 ICMPv6の場合はtype2, code 0「Packet too Big」

フラグメンテーションの問題

3つあります。

フラグメンテーションされたパケットをさらに分割してしまうと、受信側でオリジナルのフラグメントなのかサブフラグメントなのか区別がつきません。

また、最初のフラグメントが届いてからメモリ内にフラグメントを保持しておく時間をressembly timerと呼び、1つでもフラグメントが届かずタイムアウトすると、それまで受信したすべてのフラグメントを破棄してしまいます。

PMTUDの問題

PMTUDブラックホールという問題が知られてます[3] 。これは、ICMPメッセージが経路上のルータやFW等で破棄されてしまい、送信元にフラグメンテーションせよというメッセージが返ってこない問題です。もし、経路中にブラックホールがあるようであれば、送信側でMTU/MSS値を予め設定することになりそうです[4] [5]。ネットワーク側の解決策としてフラグメントに関するICMPメッセージを通したり、DFフラグを0にして無理やり分割してしまう必要があります[6] [7]。

手元でチェック

以下の2点について気になったので手元で簡単にチェックしてみました。

  • IPv4でDFフラグが1のパケットの割合
  • IPv6でフラグメント拡張ヘッダを含むパケットの割合

まずDFフラグついて。適当なサイトを10個以上開いたりメールチェックなどをしてトラフィックを発生させ、Wiresharkで通信を見てみます。キャプチャしたIPv4パケット32780個のうち、79.4%がDFフラグつきで、残り19.6%がDFなしでした。基本はDFフラグがついているようですが、何にDFフラグがついていないのかはよくわかりませんね。一応、それぞれのトラフィックの内約とパケット長の分布の図を貼っておきます。

f:id:dorapon2000:20190418221617p:plain
[DF=1] トラフィックの内約
f:id:dorapon2000:20190418221715p:plain
[DF=1] パケット長の分布
f:id:dorapon2000:20190418221747p:plain
[DF=0] トラフィックの内約
f:id:dorapon2000:20190418221815p:plain
[DF=0] パケット長の分布

次にフラグメンテーション拡張ヘッダについて。トラフィックの生成方法は先程と同じです。しかし、キャプチャしたIPv6パケット7602個のうち、フラグメント拡張ヘッダが含まれるものは1つもありませんでした。つまり、フラグメンテーションされていません。あれ?という気持ちです。どうやら、ICMPメッセージを受け取ったとき、IPのフラグメンテーション機能ではなく、TCPのMSSで管理をしてしまうのが望ましいとのことです[9] [12]。ちょうど現在IPv6のPMTUDが盛んに議論されているようでした[13]。ちなみに、IPv4でキャプチャしたほうでもMFフラグが立っているものを調べると0個でした。調べていませんが、おそらくこちらも同じような理由なのかもしれません。

IPv6拡張ヘッダのセキュリティ

別の問題として、そもそもIPv6の拡張ヘッダがあった場合、セキュリティとコストの兼ね合いから破棄してしまうルータも現実にはあるようです[8]。フラグメントヘッダのセキュリティについては、RFC7112[10]で言及されています。パケットを分割する際に、L4ヘッダは先頭フラグメントにしか付属しないため、FWがそれ以外のフラグメントをフィルタリングしたいときにL4情報を使えないという問題があります。望ましないフラグメントは禁止すべきとしています。

実際のインターネットでどれほど破棄されてしまうかはRFC7872[11]にあります。データは2015年のもので、フラグメント拡張ヘッダを付けて、Webサーバとの通信で28.26%が、メールサーバとの通信で35.68%が、ネームサーバとの通信で55.23%が、経路途中で破棄されてしまうようです。%には同じASで破棄されたものも含まれています。また、文献[8]でもDNSゾルバの37%がIPv6のフラグメントを破棄したとあります。

もっと広く使われているものだと思ってました。厳しいですね汗。

References

[1] Russ White, Ethan Banks, "COMPUTER NETWORKING PRBLEMS AND SOLUTIONS", pp.140-142, 2018

[2] Douglas E. Comer, "Comuter Networks and Internets SIXTH EDITON", pp.415-420, 2015

[3] K. Lahey, "TCP Problems with Path MTU Discovery", RFC2923 ,2000

[4] IPv6 Path MTU Discovery にどっぷりとハマる。 » かけまわる子犬。

[5] IPv6 の MTU | あたがわの日記

[6] IPv6 PMTU Discovery Blackholeの盲点

[7] Path MTU Discoveryとは - その2

[8] Dealing with IPv6 fragmentation in the DNS | APNIC Blog

[9] Fragmenting IPv6 | APNIC Blog

[10] F. Gont, V. Manral, R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC7112, 2014

[11] F. Gont, J. Linkova, T. Chown, W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC7872, 2016

[12] J. McCann, S. Deering, J. Mogul, R. Hinden, Ed., "Path MTU Discovery for IP version 6", RFC8021, 2017

[13] IPv6 Summit in Tokyo 2018 IPv6標準化最新状況