WIDE Technical-Report in 2007 USAGIプロジェクト パケットフィルタに関する開発活動 wide-tr-usagi-netfilter-02.txt WIDE Project: http://www.wide.ad.jp/ If you have any comments on this document, please contact to ad@wide.ad.jp. ^L Title: USAGIプロジェクト パケットフィルタに関する開発活動 Author(s): USAGIプロジェクトコアメンバ (usagi-core@linux-ipv6.org) Date: 2007-01-05 Filename: wide-tr-usagi-netfilter-02.txt -- 目次 1 概要 2 2006年度の開発内容 2.1 IPv4/IPv6に対応したConnection Trackingのメンテナンス 2.2 パケットフィルタの設定コマンドiptables、ip6tablesのコード共通化 3 開発体制 4 現在の状況と今後の予定 -- 本文 1. 概要 　USAGIプロジェクトはLinuxのIPv6スタックやIPv6に関するライブラリ、 アプリケーションの開発、改良を行っており、パケットフィルタ機能もその対象と なっている。今年度、USAGIプロジェクトは昨年度に引き続きIPv4/IPv6に対応した Connection Trackingのメンテナンスを行った。また、パケットフィルタの設定 コマンドiptables、ip6tablesのコード共通化を行った。以下では、これらの内容に ついて報告する。 2 2006年度の開発内容 2.1 IPv4/IPv6に対応したConnection Trackingのメンテナンス 　Connection Trackingは機器に入ってくるTCPやUDPのフローの状態変化を追跡する Linuxカーネルの一機能である。LinuxにはIPv4専用のConnection Tracking (以下ip_conntrackと記す)が実装されていたが、USAGIプロジェクトが開発した IPv4/IPv6対応Connection Tracking(以下nf_conntrackと記す)が2005年11月Linux カーネルに採用された。 　今年度、USAGIプロジェクトはnf_conntrackのコードメンテナンスを行った。その 内容は、Linuxコミュニティのメーリングリストに投稿されるパッチのレビュー、それに 伴う議論、および不具合修正である。今年度USAGIプロジェクト以外の開発者からは 主に以下のパッチが投稿された。 - 肥大化したnf_conntrackのコードを複数ファイルに分割するパッチ - ip_conntrackに実装されたアプリケーションプロトコル用モジュールを nf_conntrackへ移植するパッチ - ip_conntrackを利用したIPv4 NAT機能を、nf_conntrackを利用したものへ 移植するパッチ このように、今年度はUSAGIプロジェクト以外の開発者によるnf_conntrack関連の 開発も多く行われ、ip_conntrackからnf_conntrackへの移行が着実に進んだ。 　nf_conntrackに関連する開発が進む一方で新たな課題も出現している。その一つは、 コネクション毎に確保するメモリスペースを管理しづらいというものである。 nf_conntrackが追跡する情報はコネクションに適用する機能により異なるため、 従来のnf_conntrackはそれぞれに適した大きさのメモリスペースを確保していた。 しかしIPv4 NAT機能の対応に伴い、追跡すべき情報が動的に変更される可能性が出た。 そこで現在のnf_conntrackは、IPv4 NAT機能がカーネルにロードされている場合常に 最大のメモリスペースを確保するよう変更されている。これは一時的な処置であり、 使用メモリ量の抑制とメンテナンスの容易性を兼ね備えた方法が必要とされている。 2.2 パケットフィルタの設定コマンドiptables、ip6tablesのコード共通化 　現在LinuxではIPv4、IPv6それぞれのパケットフィルタを設定するユーザコマンドが 別々に実装されている(それぞれiptables、ip6tables)。しかし、これらは以下を扱う 処理部で類似部分を多く含むため、長らく共通化が望まれていた。 - 操作対象のパケットを選択するマッチルール用モジュール ex.: TCP/UDPポート番号によるマッチングなど - パケットに適用する操作を指定するターゲットルール用モジュール ex.: 破棄、通過許可、ロギングなど そこで、これらの実装に必要なAPIやこれらのモジュールを扱う処理部をiptables、 ip6tablesで共通化した。これにより新たなモジュールを開発する場合、共通化された APIで1つのモジュールを実装すればiptables、ip6tables両方に対応できるようになる。 3 開発体制 　昨年度に引き続き、nf_conntrackの開発に際しては、Linuxにおけるパケット フィルタやNAT機能の開発、メンテナンスを行っているNetfilter Project (http://www.netfilter.org)と密に連携しながら進めた。また昨年度USAGI プロジェクトのメンバの1人がNetfilter Projectのコアメンバとなったことで、 iptablesのコードコミット権を得た等、今年度の開発がさらにスムーズになった。 4 現在の状況と今後の予定 　2.1で述べたnf_conntrackに対する全ての変更はLinux 2.6.20に取り込まれる 予定であり、Linux 2.6.20に向けこれらの変更に伴う不具合修正等を引き続き 行う予定である。また、メモリスペースの割り当て方法について、使用メモリ量の 抑制とメンテナンスの容易性を兼ね備えた方法を開発者間で議論していく予定である。 なお、現在nf_conntrackはip_conntrackと同レベルの機能全てを実現しているため、 十分なnf_conntrackの安定化作業の後ip_conntrackはLinuxカーネルから削除される 予定である。但し、ユーザから見た使用方法に変更はない。 　iptables、ip6tablesのコード共通化については、2006年11月、Netfilter Projectの メーリングリスト上にそのパッチを投稿済みである。他の開発者からの同意を得た ため、iptables 1.4.0に取り込む予定である。なお、この変更に伴うコマンドの 使用方法についても変更はなく、ユーザはこれまでどおりiptables、ip6tablesを 利用可能である。 　ここ2年でnf_conntrackの導入、カーネルとユーザコマンドにおけるIPv4/IPv6 処理部の共通化など、パケットフィルタ関連のAPIが大きく変化している。 それに伴い開発者向けドキュメントが陳腐化しているため、今後これらドキュメントの 整備を行いたいと考えている。 Copyright Notice Copyright (C) USAGI/WIDE Project (2005, 2006). All Rights Reserved.