不明な拡張子を含むIPv6拡張ヘッダーの解析
非常に単純なネットフィルターを作成し、ICMPv6タイプ、TCP/UDPポート番号などに一致するようにIPv6ヘッダーを解析する場所に到達しています。
だから私は IPv6パケット形式 について深く読んでいて、私は...のように...まあ...実際に正しく読んでいます。 40バイトの固定ヘッダーから始めて、次のヘッダーフィールドを調べる必要があるように思えます。次に、リンクリストのように、最後に到達するまで、次のヘッダーの次のヘッダーフィールドなどを確認する必要があります。ペイロードがある場合は、それに続きます。
問題は、固定ヘッダーにも拡張ヘッダーにも長さフィールドがないことです。このリンクリストを最後まで追跡できるように、拡張ヘッダータイプとそのサイズのテーブルが必要です。
これは奇妙な、おそらくはうさぎのようなデザインであると思います。認識されない拡張ヘッダータイプが発生した場合はどうなりますか？私は何をしますか？その長さはわかりません。パケットを許可するネットフィルターでは、攻撃者が偽のヘッダータイプを含めることでネットフィルターを回避できるため、パケットを破棄してブロックする必要があると思います。 しかし、プロトコルがこれまでに拡張された場合、新しい拡張機能を使用する場合は、これまでに作成されたすべてのIPv6ヘッダー解析ソフトウェアを同時に更新する必要があります。
使用している拡張機能がわからない場合、IPv6ヘッダーを解析するにはどうすればよいですか？長さがわからないため、不明な拡張子のヘッダーをスキップするにはどうすればよいですか？
解析できないものに出くわした場合は、すでに解析した内容に基づいて決定するか、アクションを実行する必要があります。
IPv6では、各拡張ヘッダーが残りのパケットを「ラップ」するため、このように設計されています。ルーティングヘッダー、次に聞いたことのないヘッダー、次にペイロードが表示される場合、ペイロードを解析できません。ペイロードの意味は、原則として解釈方法がわからないヘッダーに依存します。
必要なのはルーティングヘッダーだけなので、ルーターはそのようなパケットをルーティングできます。ディープパケットインスペクションガジェットなどは多くのことを知る必要がありますが、とにかくそれは彼らの運命です。
追加して編集：この設計は、ミドルボックスは自分が知っていることしか変更できないことを意味します。ミドルボックスが知らないヘッダーを見つけた場合、2つのオプションしかありません：拒否または転送。 IPv4では、未知の拡張子を削除して残りを渡すこともできます。 IMOこのプロパティにより、設計の拡張性が低下するのではなく、設計が拡張されます。
認識されない拡張ヘッダータイプが発生した場合はどうなりますか？
RFC 246 から：
ヘッダーを処理した結果、ノードが次のヘッダーに進む必要があるが、現在のヘッダーの次のヘッダー値がノードによって認識されない場合、パケットを破棄し、 ICMPコード値1（「認識されない次のヘッダータイプが検出されました」）および認識されない値のオフセットを含むICMPポインターフィールドを使用して、ICMPパラメーター問題メッセージをパケットのソースに送信します元のパケット内。ノードがIPv6ヘッダー以外のヘッダーでゼロのNext Header値を検出した場合、同じアクションを実行する必要があります。
（実際には）新しい拡張ヘッダーをIPv6に追加することは不可能です。
間違っている、理由：
宛先ホストのみが認識されない拡張ヘッダーに基づいて拒否することが許可されます（その例外は リンクした質問 で言及されています）
新しい拡張ヘッダーが何らかの形でオプションである場合（それが望ましい）、そのことに関するICMPエラーを受け取り、それなしで再試行できます。
アップデート RFC 6564 は、このケースをカバーしています。それはあなたが説明するシナリオを正確にレイアウトし、新しい拡張ヘッダー（定義されている場合）のフォーマットを提示します。
新しい拡張ヘッダーを作成してIPv6を拡張するのではなく、新しい宛先オプションを追加することを意図していることに注意してください。未知の宛先オプションに対処するのは簡単なこと、または少なくともはるかに簡単なはずです。