【テクニカル・上級編】 IPv4 PPPoEとIPoE（IPv4 over IPv6 / MAP-E / DS-Lite）のルーティング性能差 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

混雑の深淵を越えて：IPoEカプセル化と、ルーターのCPUを追い詰める「見えないコスト」

夜21時、突如として低下するスループット。かつて私たちは「PPPoEの網終端装置（NTE）がボトルネックだ」と嘆き、プロバイダの乗り換えという名の神頼みを繰り返してきました。しかし、現代のインフラアーキテクトにとって、それはもはや古典的な解決策です。

今日の本題は、家庭用ネットワークの最前線に君臨する「IPv4 over IPv6」技術の内部挙動と、それが家庭用ルーターのハードウェア・リソース、特にコンテキストスイッチとCPU負荷にどのような爪痕を残すかについてです。

1. カプセル化が引き起こす「見えないオーバーヘッド」

PPPoEがPPPセッションという重厚なヘッダーを抱えていたのに対し、IPoE（MAP-EやDS-Lite）は、IPv6パケットのペイロード内にIPv4パケットを埋め込むカプセル化技術を駆使します。

ここで発生するのが、MTU/MSSの断片化問題です。カプセル化によるヘッダーの追加分（通常20〜40バイト）を考慮せず、標準の1500バイトで送出すると、途中のルーターでパケットのフラグメンテーションが発生します。これを防ぐためにTCPのMSS（Maximum Segment Size）を調整するのは定石ですが、インフラレベルで追求するなら、カーネルパラメータでの最適化が不可欠です。

特にLinuxベースのルーターやゲートウェイを運用している場合、以下のチューニングは必須と言えます。

# TCPウィンドウサイズの自動調整を最大化し、高RTT環境での帯域幅利用率を向上させる
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# カプセル化によるオーバーヘッドを考慮し、MSSクランプを自動設定する (iptables例)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

2. CPU負荷の正体：パケット処理のコンテキストスイッチ

家庭用ルーターがIPoE接続時に「非力」だと感じる最大の要因は、CPUによるソフトウェア・ルーティング（あるいはカプセル化/デカプセル化処理）のオーバーヘッドです。

高性能なASICを積んだエンタープライズ機とは異なり、家庭用ルーターは汎用的なCPUでパケットを捌きます。MAP-E（v6プラス等）では、宛先IPv4アドレスからポートセットを計算するアルゴリズムが動きます。この計算コストと、パケットの書き換え処理が積み重なると、CPUの割り込み処理が飽和し、レイテンシが急激に跳ね上がります。

特に、TLSのハンドシェイクが頻発する現代のWeb閲覧では、この「微小な遅延」がRTT（Round Trip Time）に直接影響し、体感速度を損ないます。

3. セキュリティとパフォーマンスのトレードオフ：脆弱性回避の視点

IPoE環境では、ポート制限（ポータブルなポートセット）がセキュリティの障壁となる一方、これが「ポートマッピング」の複雑さを生みます。

もしあなたが自前でゲートウェイを構築しているなら、nftablesを用いた厳格なステートフル・インスペクションを推奨します。ただし、ルールセットが巨大化するとパケットマッチングのコストが増大するため、フィルタリングは可能な限り「高速パス」に寄せるのが鉄則です。

# nftablesによる高速化されたパケットフィルタリングの例
table inet filter {
    chain forward {
        type filter hook forward priority 0; policy drop;
        # 確立済みの接続は追跡せず高速に通過させる
        ct state established,related accept
        # 必要なサービスのみを通過させる
        tcp dport { 80, 443 } accept
    }
}

4. 現場のエンジニアへ：次のステップ

パフォーマンスを極限まで引き上げるには、単に「速いルーターを買う」こと以上に、以下の観点が重要です。

ハードウェアオフロードの確認: ルーターのチップセットがカプセル化（MAP-Eのパケット変換）をハードウェアでサポートしているかを確認してください。これが無効だと、どんなにCPUクロックが高くても、高負荷時にパケットロスが発生します。
TCP BBRの導入: Linuxカーネル4.9以降であれば、輻輳制御アルゴリズムをbbrに変更することを強く推奨します。これは、損失を「ネットワークの混雑」ではなく「ランダムなパケットロス」と捉える傾向がある家庭用回線において、劇的なスループット改善をもたらします。

# TCP輻輳制御アルゴリズムをBBRに切り替え
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

PPPoEからIPoEへの移行は、単なる通信規格の変更ではなく、ルーターという名の小さなコンピュータがいかに効率的に「パケットを流し続けるか」という、終わりのないチューニングの物語です。皆さんの家庭のネットワークが、単なる「繋がるもの」から、ミリ秒単位で最適化された「インフラ」へと進化することを期待しています。

ネットワークは、正直です。設定した通りにしか動きません。だからこそ、その挙動を深く理解し、愛する価値があるのです。